I think it makes sense to go with semantic versioning. It seems like in the past, users have been confused about our current scheme and the expectation was for it to be more like semantic versioning. Therefore, we should probably just go ahead with what users were expecting in the first place.
On Thu, Oct 12, 2023 at 12:59 PM Cole Greer <cole.gr...@improving.com.invalid> wrote: > Hi Fred, > > Thanks for the suggestion, I have some concerns about CalVer mostly due to > it being a greater departure from our current versioning than a switch to > semantic versioning would be. We are already using semantic versioning if > you simply ignore the 3. If we switch to CalVer, I think the scheme which > best fits our development and support cycle would be something like > YY.MAJOR.MINOR. In this case our next major release would likely be > TinkerPop 24.1.0 (which would receive updates for roughly 2 years forming > the 24.1.x line). The 2 issues here being that we close the door on ever > having micro patch releases, and if we stick with the expected cadence of 1 > major release per year, then the MAJOR number will always be 1, there would > never be a 24.2.0 as the next major release would not land until 2025. To > fix both problems we could switch to YY.MINOR.PATCH however this scheme > would restrict us from ever doing more than 1 major release in a calendar > year. I don’t think we want to rid ourselves of that option. > > I think that semantic versioning is the most broadly understood system by > developers. Semantic versioning gives users a clear picture of the > compatibility between versions and the general scope of changes between > releases. For these reasons I would still prefer to go with a semantic > versioning scheme. > > Please let me know your thoughts on this. > > Thanks, > > Cole > > From: Fred Eisele <fredrick.eis...@gmail.com> > Date: Wednesday, September 27, 2023 at 2:56 PM > To: dev@tinkerpop.apache.org <dev@tinkerpop.apache.org> > Subject: Re: [DISCUSS] Transition to Semantic Versioning > 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 > > > Warning: The sender of this message could not be validated and may not be > the actual sender. >
