I mentioned this on the WG call this morning, but I thought I'd add my thoughts in response to this mailing list item since there may have been some confusion with my explanation.
First, I think delivering on a time-based schedule is grand. I think cutting a release once a month might be an aggressive goal, but once we get in a rhythm I believe it will become easier. Choosing a version number is an arbitrary decision. But since we appear to be following Semantic Versioning (https://semver.org/) for our numbering scheme then I believe it's best to follow those practices for choosing the next version number. Thusly, the version number will "choose itself" based on the SemVer tenants. Given the schedule, this *might* result in something like: 11/1/21: 6.0.1 - PATCH - Only bug fixes, performance changes, tooling 12/1/21: 6.1.0 - MINOR - New feature (Refetch), optionally contains PATCH items 1/1/22: 6.1.1 - PATCH - Only bug fixes, performance changes, tooling 2/1/22: 6.1.2 - PATCH - Only bug fixes, performance changes, tooling 3/1/22: 6.2.0 - MINOR - New feature (Roles/Permissions), optionally contains PATCH items 4/1/22: 7.0.0 - MAJOR - "Breaking" backwards compatibility promise. Removal of an API version or endpoint, forced changes to clients reliant on an API (like switching from Cookies to Token/Auth on all API versions) 5/1/22: 7.0.1 - PATCH - Only bug fixes, performance changes, tooling ... There are a plethora of choices in versioning. One alternative we may all be familiar with is sometimes called CalVer. Ubuntu's scheduled releases follow this scheme so their versioning represents it as a date 21.04 or 21.10. We could do something similar. The MAJOR version could still be similar to SemVer, but without the restrictions allowing us to increment once a MAJOR change has happened (Removal of PERL, for past example). The versioning scheme and schedule could then resemble: 11/1/21: 6.21.11 - November, 2021 12/1/21: 6.21.12 - December, 2021 1/1/22: 6.22.01 - January, 2022 2/1/22: 6.22.02 - February, 2022 3/1/22: 6.22.03 - March, 2022 4/1/22: 7.0.0 - MAJOR - Arbitrary 5/1/22: 7.22.05 - May, 2022 ... Windows, MacOS pick MAJOR versions in seemingly arbitrary fashion. I recall Linux choosing their MAJOR versions based on numbers of commits to the repository. I'm certainly welcome to whatever scheme we want to implement moving forward, but if we are going to deviate from SemVer's practices then I think it should be explicit. T On Tue, Oct 26, 2021 at 11:58 AM Zach Hoffman <zrhoff...@apache.org> wrote: > Seeing 2 differences: > • Aiming for a minor release every quarter instead of what we aspired > to previously, new major release every quarter > • Aiming for a patch release every month at the start of the month > > Makes sense to me, +1. > > > -Zach > > On Tue, Oct 26, 2021 at 11:44 AM Jeremy Mitchell <mitchell...@gmail.com> > wrote: > > > > Resending to make sure it's clear this is simply a proposal. Please > provide > > feedback. > > > > In the past, ATC has targeted quarterly official releases but we've > failed > > on many occasions due to "holding the bus" for certain features or slow > > release voting. In the 10/26/2021 TC working group, we discussed that we > > should stick to this schedule regardless of feature readiness. (remember > if > > you want a certain feature that was merged post-release, you can always > > pull from the master branch as we are all in agreement that master must > > ALWAYS be releasable). > > > > Here is the schedule that was proposed: > > > > - Quarterly minor releases (unless a Major is warranted and will be > > determined on case-by-case basis) > > - Monthly patch releases > > > > Example: > > > > 11/1/21: 6.0.1 > > 12/1/21: 6.0.2 > > 1/1/22: 6.1.0 > > 2/1/22: 6.1.1 > > 3/1/22: 6.1.2 > > 4/1/22: 6.2.0 > > 5/1/22: 6.2.1 > > 6/1/22: 6.2.2 > > 7/1/22: 6.3.0 > > 8/1/22: 6.3.1 > > 9/1/22: 6.3.2 > > 10/1/22: 7.0.0 <-- Apparently something "big" or non backwards compatible > > got merged (i.e. API version removal) > > 11/1/22: 7.0.1 > > 12/1/22: 7.0.2 > > > > Please provide feedback on this approach. > > > > Thanks, > > > > Jeremy >
