OK, so can we agree on this? - minor/major releases every start of a quarter (1/1, 4/1, 7/1, 10/1) - patch releases in between as determined by release manager
by that logic, we may have N patch releases between now and 12/31 and on 1/1 we will have 6.1.0 (or 7.0 if a major is warranted). Jeremy On Wed, Oct 27, 2021 at 12:52 PM ocket 8888 <ocket8...@gmail.com> wrote: > Fortunately bugfixes rarely require migrations, those are usually only for > new features, or backporting would probably be impossible. > > On Wed, Oct 27, 2021 at 10:06 AM Jeremy Mitchell <mitchell...@gmail.com> > wrote: > > > Just to be clear, cherry-picks (aka backports) (from master to the > release > > branch) should be limited to bug fixes and would only apply to patch > > releases (i.e. 6.0.1) and I would expect the release manager to determine > > if the cherry-pick is safe or not. Yes, some can be very messy and > > dangerous and IMO those should probably be punted to the next release > > branch. > > > > jeremy > > > > On Wed, Oct 27, 2021 at 8:59 AM Gray, Jonathan > > <jonathan_g...@comcast.com.invalid> wrote: > > > > > > > why not instead ask “Is it good enough?” and “Is it better than > what > > we > > > presently have?” as often as possible. > > > > > > > may not help very much, because fixing a bug is always "better than > > what > > > we > > > presently have". > > > > > > Not always. Sometimes the risks entailed with cherry-picking and > > > repatching bugfixes isn’t small. Sometimes bugfixes rely on subtle > side > > > effects or behaviors not captured in the PR. It’s not safe to assume > > that > > > taking code out of the context in which it was written and tested to be > > > inherently stable or better. > > > > > > TO specifically has a problem with the idea of cherry-picking with TODB > > > migrations. Since the migrations are linear and there still has to be > a > > > forward path from one of these cherry-picked releases, you could end up > > in > > > a situation where you’ve got database schema conflicts introduced by a > > > cherry-pick. It feels like the desire I’m reading here is wanting the > > > benefits of adopting GitFlow, while trying to still use GitHubFlow in > the > > > repo. > > > > > > Jonathan G > > > > > > From: ocket 8888 <ocket8...@gmail.com> > > > Date: Tuesday, October 26, 2021 at 10:23 PM > > > To: dev@trafficcontrol.apache.org <dev@trafficcontrol.apache.org> > > > Subject: Re: [EXTERNAL] Re: [PROPOSAL] ATC Release Schedule > > > > Thusly, the version number will "choose itself" based on the SemVer > > > tenants. > > > > > > only really works for major vs minor. Micro versions are backport-only, > > so > > > they don't necessarily have anything to do with whether or not breaking > > > changes have been made on master. Which is also why > > > > > > > why not instead ask “Is it good enough?” and “Is it better than what > we > > > presently have?” as often as possible. > > > > > > may not help very much, because fixing a bug is always "better than > what > > we > > > presently have". > > > > > > Essentially it seems like our release cadence wouldn't actually change > > very > > > much, the proposal isn't to get rid of the quarterly releases we strive > > > for, but just adding a plan to backport bug fixes every month. Which, > we > > > could also decide not to do, if no bugs were fixed that month, or if > it's > > > too much trouble to backport the fix - "as-needed" as Jeremy puts it. > The > > > big difference is we typically only do micro releases for critical bugs > > > that slipped through the validation process, or for security fixes, > > whereas > > > under the terms of the proposal we'd make an effort to collect things > > that > > > could be fixed in supported releases every month. > > > > > > > asking folks to vote on new RC every few weeks isn’t feasible unless > > it’s > > > a standing “good enough” process > > > > > > that would definitely be better, but I think we hope that few enough > > things > > > are going into micro releases, with very little unknown since the last > > > minor, that validation could be focused just on "are these bugs > actually > > > fixed?" Could be harder with non-trivial backports, to be sure. It > would > > > definitely be better to have that process, and it's definitely > possible a > > > micro version gets too big or complex to validate cleanly. In that > case, > > > the release fails, which honestly isn't a big deal if there's no > critical > > > bug or security fix. > > > > > > On Tue, Oct 26, 2021 at 9:02 PM Jeremy Mitchell <mitchell...@gmail.com > > > > > wrote: > > > > > > > So the idea behind regularly-scheduled, predictable patch/minor/major > > > > releases was a couple of things: > > > > > > > > 1. setting release schedule expectations with the open source > community > > > (as > > > > Dave said). i.e. you can expect a minor/major release 1x a quarter > and > > > > patch releases in between (monthly) > > > > 2. removing the ambiguity of what a minor/major release contains. it > > > simply > > > > contains whatever was merged in that quarter. nothing to plan. > nothing > > to > > > > debate. > > > > > > > > The truth is feature-based release planning is hard and requires a > lot > > of > > > > communication. I don't believe we have the level of communication > > > required > > > > (via working group or mailing list) to effectively pull off > > > feature.-based > > > > releases, hence, time-based seems like the better option for us IMO > and > > > if > > > > we go that route, we need to stick to the schedule to be successful. > > > > > > > > Yeah, I get it. Going from quarterly releases (which we've failed at) > > to > > > > monthly seems like the wrong direction. What if we change NOTHING and > > > > recommit to our quarterly major/minor releases with patch releases > > being > > > on > > > > an as-needed basis coordinated by the release manager? So basically a > > big > > > > no-op. :) > > > > > > > > Jeremy > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Oct 26, 2021 at 7:16 PM Dave Neuman <neu...@apache.org> > wrote: > > > > > > > > > Resending because I don’t think it went to the list last time. > > > > > > > > > > I agree that releasing whenever we have something worth releasing > is > > > > ideal, > > > > > however I think with an open source project we should set > > expectations > > > of > > > > > some sort of release schedule. > > > > > > > > > > I also agree that we should be striving to automate as much as > > possible > > > > to > > > > > make our releases easier. That is something that takes time and > > > effort, > > > > we > > > > > have made great progress and I have no doubt that we will continue > to > > > do > > > > > so. > > > > > > > > > > On Tue, Oct 26, 2021 at 17:27 Gray, Jonathan > > > > > <jonathan_g...@comcast.com.invalid> wrote: > > > > > > > > > > > Instead of trying to focus on a cadence of an arbitrary calendar > > > > > schedule, > > > > > > why not instead ask “Is it good enough?” and “Is it better than > > what > > > we > > > > > > presently have?” as often as possible. The first question > > addresses > > > > > > partially implemented features or roadmap items. The latter > > > addresses > > > > > code > > > > > > stability and the state of confidence in the software. > > > > > > > > > > > > I have a moderately high bar as it is exercising the latest > merged > > > > > commits > > > > > > every day from scratch on new infrastructure to at minimum > > > successfully > > > > > > pass known traffic on a variety of delivery service > configurations. > > > If > > > > > > that passes, it’s “good enough” to me. That’s not to say it’s > bug > > > free > > > > > or > > > > > > perfect, but it’s an increasing bar on top of what we already > > enforce > > > > on > > > > > > the merge of PRs as it is. Also, to say something is “good > enough” > > > > > doesn’t > > > > > > mean it can’t be better. How you know what “good enough” is > > > > evolutionary > > > > > > and hopefully cumulative. Our project has a difficult challenge > > that > > > > > it’s > > > > > > not just one single application. It’s a complex system of > > > interactions > > > > > of > > > > > > multiple pieces of software in particular ways. With the current > > > state > > > > > to > > > > > > support anything technically possible via both ATS+ATC, there is > no > > > > > “done” > > > > > > when it comes to improving automated stability validation. > > > > > > > > > > > > Cutting releases is real work, so it’s something that we’d have > to > > > > weigh > > > > > > out too. Release whiplash asking folks to vote on new RC every > few > > > > weeks > > > > > > isn’t feasible unless it’s a standing “good enough” process that > > > didn’t > > > > > > require humans to do anything. Don’t get me wrong, calendars and > > > goals > > > > > > aren’t bad, but those basic questions don’t have to wait 1-3 > months > > > > > before > > > > > > they’re asked and really are more important. To me at least it’s > > > also > > > > ok > > > > > > to abandon a release if it turns out during the RC process it’s > got > > > > > > critical flaws, so we don’t end up cherry-picking and fixing up > > > patches > > > > > > moving the next cadence window further and further out. > > > > > > > > > > > > Jonathan G > > > > > > > > > > > > > > > > > > From: Dave Neuman <neu...@apache.org> > > > > > > Date: Tuesday, October 26, 2021 at 4:02 PM > > > > > > To: dev@trafficcontrol.apache.org <dev@trafficcontrol.apache.org > > > > > > > > Subject: [EXTERNAL] Re: [PROPOSAL] ATC Release Schedule > > > > > > 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://urldefense.com/v3/__https://semver.org/__;!!CQl3mcHX2A!Q7m483_Mi3eCFQqXNwoXRG_EA0fdl7zl1R6ecyfz7auYIYCuI5rcDvl2EfkIcooWVEU3$ > > > < > > > > > > https://urldefense.com/v3/__https:/semver.org/__;!!CQl3mcHX2A!Q7m483_Mi3eCFQqXNwoXRG_EA0fdl7zl1R6ecyfz7auYIYCuI5rcDvl2EfkIcooWVEU3$ > > > > > > > > > > ) 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
