git.net

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

Re: A proposal...


On Thu, Apr 26, 2018 at 10:13 AM, Jim Jagielski <jim@xxxxxxxxxxx> wrote:
>
>> On Apr 25, 2018, at 1:50 PM, William A Rowe Jr <wrowe@xxxxxxxxxxxxx> wrote:
>>
>> Because of our conflation of patch and enhancement,
>
> It is hardly just "our"... tons and tons of s/w uses the patch number bump for not only patches but also features and enhancements, including our "competitors".
>
> I still fail to see anything which leads me to believe that our numbering is the core issue that must be fixed. I am extremely open to my mind being changed :)

It is not numbering, for sure. There are dozens of approaches to that which
throw all the changes into the blender, and dozens of approaches which keep
bug fixes and maintenance distinct from enhancements and feature creep.
Semantic Versioning is only interesting here because it is a strategy that was
successfully adopted by the APR project, our fellow Subversion project and
even our highly valued nghttp2 dependency.

What I've seen suggested is to put httpd into a "sleep" mode for the duration
of a longer-running RC cycle of a week or so, easily stretched out into a month
or more for complex additions. Putting the release branch to sleep for a month
impedes new development efforts, and puts us in a pretty precarious position
if a zero-day or very critical security report surfaces. Feature or change is half
ready, so such critical fixes comes with new risk.

Any policy and versioning scheme which allows maintenance changes to be
released on a regular basis, and allows new development to proceed at full
steam when any particular committer is able to contribute their volunteer time,
and lets the community test those enhancements and experiments without
disrupting users relying on a stable platform would be a win. Modifying the
RC proposal to fork from the time of -rc1 and have a 2.4.34 release branch
for a month, while 2.4.35 continues at pace is one alternative solution.

There, the -rc is simply a different wording of -alpha/-beta. This means 2.4.35
may be released with critical bug fixes long before 2.4.34 is ready to go. Or
we renumber the 2.4.34 branch to 2.4.35 and release a very limited 2.4.34
of strictly critical fixes, curated in a rush, when such events happen or serious
regression occurs. For early adopters at 2.4.34-rc1, and editing all of the
associated docs changes to reflect the renumbering would be a headache.
This is part of why httpd declares version numbers are cheap.

What seems to be agreed is that the even-odds way of approaching things
was a short term fix which didn't move us very quickly, bogged down major
new efforts, and sits basically abandoned.

What seems apparent is that conflating enhancements with getting fixes
into users hands is that users don't get fixes, including for enhancements
recently introduced, for months on end. Reflecting on our current state and
six years of activity, and you can look at this from the lens of using RC's
or semver semantics;

 tag     mos (since prior GA tag)
2.4.33 GA  5mos Mar 17 18 minor
2.4.32 rc  5mos Mar 09 18 minor-beta
2.4.31 nr  5mos Mar 03 18 minor-beta
2.4.30 nr  4mos Feb 19 18 minor-beta (security +1 mos GA delay)
2.4.29 GA  1mos Oct 17 17 minor
2.4.28 GA  2mos Sep 25 17 minor (security)
2.4.27 GA  1mos Jul  6 17 patch (security)
2.4.26 GA  6mos Jun 13 17 minor (security)
2.4.25 GA  6mos Dec 16 16 minor (security)
2.4.24 nr  6mos Dec 16 16 minor-beta
2.4.23 GA  3mos Jun 30 16 minor (security)
2.4.22 nr  3mos Jun 20 16 minor-beta
2.4.21 nr  3mos Jun 16 16 minor-beta
2.4.20 GA  4mos Apr  4 16 minor (security)
2.4.19 nr  3mos Mar 21 16 minor-beta
2.4.18 GA  2mos Dec  8 15 minor
2.4.17 GA  3mos Oct  9 15 minor
2.4.16 GA  6mos Jul  9 15 minor (security +5 mos GA delay)
2.4.15 nr  5mos Jun 19 15 minor-beta
2.4.14 nr  5mos Jun 11 15 minor-beta
2.4.13 nr  5mos Jun  4 15 minor-beta
2.4.12 GA  6mos Jan 22 15 minor (security +2 mos GA delay)
2.4.11 nr  6mos Jan 15 15 minor-beta
2.4.10 GA  4mos Jul 15 14 minor (security)
 2.4.9 GA  4mos Mar 13 14 minor (security)
 2.4.8 nr  4mos Mar 11 14 minor-beta
 2.4.7 GA  4mos Nov 19 13 minor (security)
 2.4.6 GA  5mos Jul 15 13 minor (security +2 mos GA delay)
 2.4.5 nr  5mos Jul 11 13 minor-beta
 2.4.4 GA  6mos Feb 18 13 minor (security)
 2.4.3 GA  4mos Aug 17 12 minor (security +2 mos GA delay)
 2.4.2 GA  2mos Apr  5 12 minor (security +1 mos GA delay)
 2.4.1 GA 38mos Feb 13 12 major
 2.4.0 nr 37mos Jan 16 12 major-beta
2.3.16 rc 36mos Dec 15 11 major-beta
 2.3.0 rc start Dec  6 08 major-beta

2.4.27 illustrates that we can turn around a patch quickly when the
other churn is excluded. (2.4.29 illustrates that we can even add
new features and release a minor update in a month, but our track
record proves this is the exception, not the rule.)

Our present versioning schema doesn't allow us to deliver this
software on a consistent or predictable or stable basis. That's
why I started the conversation wide open to different versioning
schemas and policy suggestions. There are lots of alternatives.
Starting with issuing easy-to-review patch releases which are
not overloaded with all the new goodies to slow down putting
our fixes in user's hands promptly.