1.0.0 Release Planning

[alexlafroscia]

I think it would be useful to figure out what should constitute the "bar" to meet for releasing 1.0.0 of this addon.

Pre-1.0.0 software can be hard to consume; every release can contain breaking changes without violating SemVer, meaning consumers need to be extra careful when upgrading their apps. Package managers will often avoid deduplicating multiple versions of pre-1.0.0 software for the same reason, which can cause dependency maintenance headaches for consumers. Thus, I think it would be nice to get out of a pre-1.0.0 version as soon as possible.

If we wait until we have a complete set of the HeadlessUI components, with all of their functionality implemented, it could be a long while before this addon matures to a non-prerelease version. I would propose that instead of targeting that as the criteria for releasing 1.0.0, we instead determine some other set of criteria that should be met.

[alexlafroscia]

Here's my proposal for what 1.0.0 should include:

I think that we should focus on "completing" the existing set of components and, once that has been done, cut the initial release. That set of components would be:

1. Dialog
2. Menu
3. Switch

"Complete" to me means two things:

1. All of the tests for the component that exist in the "upstream" version of HeadlessUI (the React/Vue implementations) have an equivalent test here. Some tests might not be relevant, but those should be minimal and documented. All of the core functionality -- keyboard controls, accessibility requirements, etc -- should match 1:1
2. Documentation exists for the component beyond the usage in the test suite. This could be in a README, but more likely we should extend the documentation site to cover this. I'm imagining documented usage examples that show the code and rendered output. We probably don't have to write a ton of documentation on when to use each component; HeadlessUI itself does a good job of this, and we should probably defer to their documentation as much as possible. I think "good enough" documentation would be showing some recipes for how to pull off some common use-cases.

[GavinJoyce]

This is great Alex, sounds good to me.

When we do add new components (I think @achambers may want to do that for his own use), we can clearly label them as experimental while they are being iterated.

[alexlafroscia]

we can clearly label them as experimental while they are being iterated.

I think that's a great idea!