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
