Closed 6543 closed 11 months ago
Maybe we should have a more "living standard" like approach. The actual process results in a new version, even for very small changes, which is not really ideal.
...or to go a more community driven way and make more use of the meta-structure (like you referenced in #70) and focus on a FEP like process (or maybe even use the FEP process) https://codeberg.org/fediverse/fep
So far we've just copied over the most recent schema version to the anticipated next version number and tag it off once satisfied, publishing it to the website with the tagging. I could also see to keep something like a -develop
or -next
version and have the release process copy that to a concrete version.
-> #74
Ok B is answered too now.
I'll create a new issue to summarize the development and keep that up to date, you might pin it for better discoverability
-> #76
we should decide on two topics:
how to develop new one
A. just create a new folder at ./schemas, copy the current one and alter after via pull requests B. branch out and alter the current one until ready, if it's ready copy it and create a new version out of that C. suggestions :)
what version is next
A. after a long time indicate with 3.0 that software should adopt it B. just follow strickt semversioning -> 2.2 (untill we agree that a breaking change is needed)
followup to #70's conversation