> On Apr 20, 2018, at 8:28 AM, Micha Lenk <mi...@lenk.info> wrote: > > Hi Jim, > > On 04/20/2018 01:46 PM, Jim Jagielski wrote: >> Where numbers and versioning DOES matter is how it affects >> distributors and vendors of httpd and the entire module eco-system. > No, it doesn't. There are way too many variants of versioning schemes out > there in use by so many OSS projects that the distributors and vendors need > to be prepared to encounter any variant you can imagine. >
We have a history, as well as a published "agreement" on what minor version numbering means. Our module eco-system is huge and we need to factor/consider not only the big players, but also the solitary developers who have modules. It is a long, long history and if/when we need to reconsider versioning, the impact will not be insignificant. > What matters is quality (here I do agree with you). A versioning scheme can > help to establish certain rules of what to do and more importantly what to > *not* do on a given version pattern or branch. And with the current rate of > successful releases, apparently the current rules either were not enforced > well enough or otherwise were not good enough and thus need to be changed. A > new versioning scheme then could help to establish new, hopefully better > rules. Or just change the goalposts... if, as you say, our current version-scheme rules don't work as far as limiting/controlling what we can do (which I don't agree with, btw), then simply replacing it with another version-scheme likely won't do anything as well. Again, I don't think numbers or names are the issue at hand, at core, but rather, maybe, overconfidence in how we have been doing release QA and testing. For example, and I am certainly guilty of this, the original concept was that "new stuff" was put in trunk, and allowed to mellow and age, for a "bit" at least, to get a feel for how well it works. After "awhile", when things looked like it was "ready for prime time", it would be proposed for backport. Today, right after something is committed to trunk there is almost invariably, in the next commit, a backport proposal for it to be in 2.4. Now for bug fixes, etc, that likely makes some level of sense, but lately, it seems like committing to trunk is just a tic-mark. Again, it is all in balance, and likely we've just not achieved that lately due to the extreme complexities of the eco-system around, internal, external and dependent upon us.
