Tagging 1.0.0 with four features missing, on purpose

Atelier went 0.1.0 to 1.0.0 in four weeks and eleven releases. The last one was mostly a decision.

The two bars people confuse

Docs/tasks/14-v1-release.md was written on 3 September specifically to keep them apart.

The product bar is the eleven success criteria in the PRD. Drag to reorder was the last unmet one, and it landed in this release.

The package bar is what 1.0.0 promises a stranger who runs composer require: a named public API, a support matrix CI actually tests, a suite that runs from a clone, and documentation that is true.

Below 1.0.0 a minor release may break anything, and the changelog says so. That freedom is worth having while the shape moves and worth losing once client projects depend on it. So the cost of tagging too early is one specific thing: a rename inside Block, AtelierPlugin or the config keys becomes a 2.0.0 instead of a footnote.

Which means the tag is a statement about names, not about scope.

What the number actually covers

A table in the README, because a promise nobody can read is not a promise:

• Block and BaseBlock, PageType and BasePageType
• AtelierPlugin's registration methods
• The documented methods on Page, plus Media, Tokens, Url, MenuSource
• Two head partials, and data-atelier-canvas as the layout contract
• Every key in config/atelier.php
• Column names and shapes in six tables

And, just as importantly, what it does not cover: the registries, everything under src/Filament/ and src/Http/, the renderer, the shared controls. Those are internal and free to move in a minor. Naming the internals is what stops a 1.0 from freezing the whole codebase by implication.

What is missing, and why it did not block the tag

Four blocks from the v1 scope do not exist: header, footer, contact form, raw HTML.

Header and footer are arguably answered by layouts plus the menu manager, which arrived after the list was written. The honest move is to strike them from the PRD with a dated banner, and I have not done that yet, so they stay listed as owed.

The contact form is blocked by an open question that has been open since August: where a submission should land. A table, an email, a CRM. A package that picks one is wrong for most projects, and one that supports all three has a configuration surface bigger than the feature. The example app now ships a working one written in the host app, which is the shape the answer will take.

Raw HTML is the genuinely missing one, named in the project's own non-negotiables as the escape hatch for one-off markup. It is an afternoon. It did not happen this week.

Also deferred: Core Web Vitals were never measured, per-block asset loading does not exist, there is no revisions UI, and the menu manager still ships behind an experimental flag, which means the criterion it satisfies is met by a feature nobody sees by default. That criterion moves to 1.1 rather than being called met.

Saying it out loud is the whole trick

All of that is in the release notes and in the gate file with dates. Not because transparency is a virtue in the abstract, but because deferred and forgotten look identical from outside a repository, and the difference is exactly what someone deciding whether to depend on your package is trying to work out.

"Not built yet" in the README is a section I have kept accurate since the first release, and it is the part I would keep if I could only keep one.

The bit I would do differently

I tagged 0.5.0 four hours before 1.0.0. Two releases in a day, because page types felt like a version and then the editor work felt like a version, and the number in between never reached anyone.

The honest version is one release with both in it. The changelog is right either way, but a version nobody installed is bookkeeping rather than a release.

Where it stands

v1.0.0, on Packagist, with 232 tests, a wiki that matches the code and a demo site you can click through end to end.

Not finished. Named.