Limit scope of instability

[codeflo]

The homepage currently states that breaking changes are to be “expected”, and issue #208 explains that the current priority is on “finding the right featureset […] over reaching stability”. Both of those are refreshingly clear.

However, going forward, I wonder if there’s a path to some kind of “partial stability” before a full 1.0 that would already enable some production usecases, while not unnecessarily restricting further development and experimentation.

I’m thinking along the lines of marking a subset of features as “conditionally stable”. The idea would be that for people relying on those features, there would be a best effort to offer a migration path.

In particular, while those features or their API could change, they would be unlikely to be removed without any replacement. This would also imply offering a migration path for any changes to the underlying storage, see e.g. #433.

Anyway, that’s just a quick thought, I could be completely off the mark here.

[joepio]

Hi @codeflo, thanks for taking the time to share your interesting thoughts!

Having a list of things that are unlikely to be be removed or (severely) changed would be of value to potential users. I think that for many features, this is already the case. I think adding a STATUS.md file, describing stability of various features might be the way to go. Or maybe a page on atomic-data-docs. Anyways, one living document that contains a more detailed status report that specifies which features are (conditionally) stable.

This would also imply offering a migration path for any changes to the underlying storage, see e.g. #433.

I would definitely offer a (fully automated) migration path. Atomic-server auto-migrates whenever it is needed. Maybe I should communicate this more clearly.

[joepio]

@codeflo I've written a draft version. Does this look like what you had in mind?

https://github.com/atomicdata-dev/atomic-data-rust/pull/557/files

[codeflo]

That's awesome, thanks!

[joepio]

Status.md is now part of the repo, and referred to from README and CHANGELOG!

Thanks @codeflo !