git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])


I'm not sure where in the conversation to add this, but I do want to
point out a mechanical concern.


If we end up with API and feature freeze on branch 2.4, then we'd expect
to roll 2.6. Soon enough, we'll hit a situation where 2.6 (as a release
branch) can't get a feature or the next great thing because of a
required API incompatible change. We would then kick out 2.8, 2.10 and
so on and so forth. This seems like it would satisfy both the
keep-the-stuff-stable as well as the give-users-new-stuff "sides".


Mechanically, this can become tiresome for a volunteer as we work
through the STATUS ceremony for each of the branches. I remember that
being less than enjoyable when 2.0, 2.2 and 2.4 were all release
branches. I'm fearful of a future where we may have five branches and a
bugfix applicable to all (or worse... a security fix that would dictate
all should be released/disclosed at the same time).

-- 
Daniel Ruggeri

On 4/19/2018 7:17 PM, William A Rowe Jr wrote:
> I don't disagree with RC's entirely, or the mechanism you suggest, but
> that isn't what I read as proposed.
>
> Our issue is that every httpd must be distinguished, we won't ship
> four tarballs all claiming 2.4.34 (GA). Which one is the person
> complaining about? Are we back to SHA signature of the source tarball
> (that isn't even assuredly what they built the binary from?)
>
> We can decorate the rc in the versioning, but that isn't part of 2.4.x
> API, unless we swap out the "-dev" string tag for an "-rc#" value.
>
> It is not reasonable to lock a branch for an indeterminate length of
> time. Branching the RC into what becomes the final release, and making
> it painful to backport first to 2.4.x and finally 2.4.n-rc branch
> might help discourage disruptive backports, but there is no suggestion
> yet of what is acceptable, either on such a frozen main branch or rc
> branch.
>
> In fact our policy reflects that two competing release candidates is
> an entire valid and even expected situation, and any process that
> further blocks this should be firmly rebuffed.
>
> As it reads so far the proposal is the way we do things, now
> conserving subversion numbers as precious, if only to reenforce a
> stake in the ground that version major and minor numbers are similarly
> precious, (which they are not.)
>
> With the addition of freezing changes on 2.4.x branch for a time we
> succeed in impeading progress towards version .next, while not
> otherwise changing the status quo.
>
> What you suggest is yet another thing, based on forking the RC release
> branch, and I haven't seen that accepted by the committee yet.
>
> On Thu, Apr 19, 2018, 16:43 David Zuelke <dzuelke@xxxxxxxxxxxxxx
> <mailto:dzuelke@xxxxxxxxxxxxxx>> wrote:
>
>     The main difference is that you have a release branch in which fixes
>     to bugs or regressions found during 2.4.x RCs can be made, while work
>     on 2.4.(x+1) can continue in the main 2.4 branch.
>
>     Another benefit is that people who do automated builds (e.g. me) can
>     grep for "RC" in the version number and have it fetch from
>     https://dist.apache.org/repos/dist/dev/httpd/ instead.
>
>     The changelogs are more readable as well, because it's obvious which
>     intermediary RC releases belong together. If you look at
>     https://archive.apache.org/dist/httpd/CHANGES_2.4, there is zero
>     indication that e.g. 2.4.31 was never released.
>
>
>     On Thu, Apr 19, 2018 at 10:53 PM, William A Rowe Jr
>     <wrowe@xxxxxxxxxxxxx <mailto:wrowe@xxxxxxxxxxxxx>> wrote:
>     > What possible improvement occurs if there is no branch discipline
>     > on 2.4.x development? We just echoed effectively your proposal,
>     > using numbers rather than RC designations, and still .33 has this
>     > host of issues. With no release since .29, the branch was in this
>     > continuous state of flux between 2.4.30 and 2.4.33. Testing the
>     > 2.4.30 release did not result in a better, eventual 2.4.31, testing
>     > .31 didn't result in a better .32, and even the final .33 had
>     its own
>     > issues.
>     >
>     > This would have been precisely the same outcome between RC1
>     > and RC4, if the project doesn't keep the branch stable for even the
>     > week or months required to craft a successful release, and if that
>     > occurs on 2.4.x branch, that is an interruption of effort towards
>     > release n+1, frustrating contributors.
>     >
>     > Note we don't publish anything not approved by the PMC, so
>     > there would be the same "vote" to release an RC.
>     >
>     > Net <-> net, this is the status quo which failed us so badly this
>     > past winter (now with alphabetic characters!)
>     >
>     >
>     > On Thu, Apr 19, 2018 at 10:51 AM, Jim Jagielski <jim@xxxxxxxxxxx
>     <mailto:jim@xxxxxxxxxxx>> wrote:
>     >> The idea is encouraging and fostering a broader test audience.
>     >>
>     >>
>     >> On Apr 19, 2018, at 11:44 AM, William A Rowe Jr
>     <wrowe@xxxxxxxxxxxxx <mailto:wrowe@xxxxxxxxxxxxx>> wrote:
>     >>
>     >> Unless I misunderstand...
>     >>
>     >> 2.4.30-RC1 (rejected)
>     >> 2.4.30-RC2 (our .31, rejected)
>     >> 2.4.30-RC3 (our .32, rejected)
>     >> 2.4.30-RC4 -> 2.4.30 GA (our 2.4.33 release)
>     >>
>     >> With all the associated changes in between, no actual change in
>     branch
>     >> management, scope, feature creep, etc?
>     >>
>     >> This sounds like dressing up the status quo with different labels.
>     >>
>     >>
>     >>
>     >> On Thu, Apr 19, 2018, 10:37 Jim Jagielski <jim@xxxxxxxxxxx
>     <mailto:jim@xxxxxxxxxxx>> wrote:
>     >>>
>     >>>
>     >>>
>     >>> > On Apr 19, 2018, at 11:26 AM, William A Rowe Jr
>     <wrowe@xxxxxxxxxxxxx <mailto:wrowe@xxxxxxxxxxxxx>>
>     >>> > wrote:
>     >>> >
>     >>> > On Thu, Apr 19, 2018 at 10:11 AM, Jim Jagielski
>     <jim@xxxxxxxxxxx <mailto:jim@xxxxxxxxxxx>> wrote:
>     >>> >> With all this in mind, should we try to set things up so
>     that the
>     >>> >> next release cycle uses the concept of RCs?
>     >>> >>
>     >>> >> If so, and if people like, I can come up with a baseline
>     >>> >> proposal on the process for us to debate and come to
>     >>> >> some consensus on.
>     >>> >
>     >>> > Would you define an RC? What changes are allowable in that
>     branch?
>     >>>
>     >>>
>     >>> The idea is that right now we take an existing state in SVN
>     >>> and tag it as, for example, 2.4.121. We then vote on that tag
>     >>> and the artifacts released from that tag. No work is done on
>     >>> the 2.4 branch while testing is done so that we ensure that
>     >>> the SVN rev on branch == the one for the tag
>     >>
>     >>
>     >> Not necessary to freeze; a tag can always be applied to an
>     older rev.
>     >>
>     >>> Instead, we tag at 2.4.121-RC1. We do the exact same. If the
>     >>> vote does not pass, we continue on the 2.4 branch, fix the
>     >>> issues, and then tag a 2.4.121-RC2. Rinse and repeat.
>     >>>
>     >>> If the vote does pass we tag the branch, which is still == RC#
>     >>> at this stage, as 2.4.121 (ap_release.h mods included). We
>     >>> still even at this stage test and vote on the release as we have
>     >>> for decades. If it passes, we release. If not, for some reason,
>     >>> we have burned the 2.4.121 release, bump to 2.4.122 and GOTO
>     >>> the above.
>     >>>
>     >>> This is the overall idea... more flesh to be added.
>     >>
>     >>
>