sure, seems like what we originally agreed to :)
On Tue, Nov 2, 2021 at 3:17 PM Jeremy Mitchell <mitchell...@gmail.com> wrote: > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
