What about CalVer? https://calver.org/ There have been TinkerPop versions in the past which were quite different 1, 2, 3. I would expect a version 4 (as some proposals suggested). It seems that this major version number is part of the product name more than just a version.
On Wed, Sep 27, 2023 at 4:14 PM Cole Greer <cole.gr...@improving.com.invalid> wrote: > Hi everyone, > > I think now is a good time to start thinking about 3.7.x development from > master into 3.7-dev and to setup master to take breaking changes for the > next major release. I opted to delay this after the last release to > temporarily save some of the admin burden of 4 active branches. > > I think this gives a good opportunity to revisit our versioning scheme. > The current scheme ( > https://tinkerpop.apache.org/docs/current/dev/developer/#versioning) is > EPOCH.MAJOR.MINOR.PATCH, where EPOCH has been fixed at 3 since 2015, and > the PATCH digit has never been utilized. > > I suggest that we move to a more standard semantic versioning scheme ( > https://semver.org/) with just MAJOR.MINOR.PATCH starting with 4.0.0. I > would expect the MAJOR and MINOR numbers to essentially retain the same > roles as they have now (4.x.x -> 5.0.0 would be comparable to 3.6.x -> > 3.7.0). I don’t expect we would utilize the PATCH release often, but I > would for it to be a formalized process for publishing partial releases > (perhaps only updating a single component) which can hopefully skip much of > the overhead of a full release. We’ve previously deployed release-candidate > convenience binaries for some GLV’s in the past for certain users in this > fashion, it would be good to bring this into a proper release. > > I believe this versioning system is more aligned with what most developers > are used to. Additionally, I hope that dropping the EPOCH value will allow > us to be a little more aggressive with changes in major releases (perhaps > introducing a type system or schema capability). > > It would also be useful if we started publishing end-of-life dates for > major releases to give users a clearer picture of expected support. I would > suggest as a starting point 1 year of active support (adding new features, > acting as the main target branch for non-breaking changes) and 2 years of > security support (branch is kept open for critical bug fixes and security > patches). If we plan to maintain roughly 1 major release per year, this > remains somewhat in line with current support timelines. We would > presumably retain the right to do additional releases for a branch beyond > the promised support window if we ever deemed it necessary. > > Let me know if you have any thoughts on this change. If there is no > feedback, I will assume a lazy consensus in favour of adopting semantic > versioning and moving the master branch to 4.0.0-SNAPSHOT development. > There are still some details to be worked out regarding patch releases > under the new system (it isn’t completely fleshed out for the current > system either). I intend to follow up soon with a more specific patch > release proposal depending on the feedback here. > > Thanks, > > Cole Greer >
