So we are trying to address our inability to meet our current release goals by adding more releases? Why don't we just try to get more consistent with the quarterly releases before we change things? If we need to do a patch release it is probably because some critical issue was found, are we really going to wait for the beginning of the month instead of just releasing it and fixing that issue ASAP? Maybe I am missing some context here but this seems like we are trying to solve a problem with more process instead of trying to get better at what we already agreed to?
On Tue, Oct 26, 2021 at 1:04 PM Taylor Frey <taylor.f...@gmail.com> wrote: > 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 > > >
