On Sun, Apr 22, 2018 at 11:34 AM, Daniel Ruggeri <[email protected]> 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)
