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)])




On Sun, Apr 22, 2018 at 11:34 AM, Daniel Ruggeri <druggeri@xxxxxxxxxxx> wrote:
Yeah - I think my main concern is really just around the backporting
process with STATUS and how that will have issues scaling across many
branches. Further, as each branch deviates, it becomes more of a
cognitive exercise for developers to figure out if the fix in branch XYZ
is applicable and the same in ABC.

The more I think about it, the more I *really* like a semver-ish
approach where major represents the ABI that will not be broken, minor
represents the feature set (for backwards compatibility) and patch
represents forward-compatible changes/fixes.

Apache Subversion takes the patch number much more literally. They are merely fixes to behavior defined in the minor release. The API/ABI is never touched during a patch release. You could build against 1.7.13, then install 1.7.0 and your code works against it. Then upgrade svn to 1.7.20 and it still works. Downgrade to 1.7.5 ... you get the picture.

I see several issues with the recent threads of discussion:

* How releases are numbered, and what guarantees are made relative to those numbers
* What kinds of gating of features/fixes is defined by the process?
* How are branches created/maintained, relative to the above

Classic httpd numbering can certainly be made to work (empirically: it has). semver is well-documented, understood, and downstream users would not need to understand our quirks. It does kind of impose decisions on gating of features, though (Q2 above).

It is unclear what problem is being solved. It seems like the unpredictable feature set of 2.4.x. And/or when to stop loading features into that, and start a 2.6.x series. (or 3.0?)

Cheers,
-g

ps. my vote is for semver and strict controls on patch releases. chew through release numbers. they are cheap. downstream will pick one release and run with that. it doesn't matter to them if we have a new minor every six months (which means new features, which distros won't pick those features from patch releases anyways; may as well move them to a minor)



( ! ) Warning: include(msgfooter.php): failed to open stream: No such file or directory in /var/www/git/apache2-developers/msg03872.html on line 78
Call Stack
#TimeMemoryFunctionLocation
10.0006368760{main}( ).../msg03872.html:0

( ! ) Warning: include(): Failed opening 'msgfooter.php' for inclusion (include_path='.:/var/www/git') in /var/www/git/apache2-developers/msg03872.html on line 78
Call Stack
#TimeMemoryFunctionLocation
10.0006368760{main}( ).../msg03872.html:0