> On 20.01.2017, at 15:34, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> On Thu, Jan 19, 2017 at 6:12 PM, David Zuelke <d...@heroku.com> wrote:
>> I don't know any framework/language/library out there that handles it that
>> strictly. Nginx, or Ruby, or PHP, or whatever...
>>
>> From x.y.z to x.y.z+1, retain full compatibility.
>>
>> From x.y.z to x.y+1.0, keep external API compatibility, break ABI if needed,
>> break internal API if absolutely needed
>>
>> From x.y.z to x+1.0.0, break anything you want.
>>
>> One issue IMO is that there are a lot of things in flight for 2.6 and 3.0,
>> and some of these are features, while other are big architectural overhauls.
>> The former are for 2.6, and the latter very clearly belong into 3.0. There's
>> no reason why both can't be worked on concurrently.
>
> That's what I'm proposing... a model where x.y.[0-#] releases remain
> consistent,
> like all the packages you mention above, and unlike httpd.
>
> I liked your highlight of "if [absolutely] needed". That's where our
> trunk (2.next)
> has spent four years diverging from 2.current, mostly unnecessarily.
>
> The fact that the code *could* be backported to 2.4.x (in your PHP and Ruby
> examples, such backports aren't even acceptable) means that it *could* have
> stayed consistent on our 2.next trunk.
I'd actually like to question the whole practice of porting features back to
older branches. I think that's the core reason why trunk is in total disarray,
and why no substantial releases have been made. There is just no reason for
anyone to push forward the state of 2.6 or even 3.0 if you can just backport
whatever you want.
Just define 2.4 as "bug fixes only" the moment 2.6 is released, and start the
process of getting 2.6 out ASAP. In fact, why not declare 2.4 that right now?
It's already "stable". It doesn't need more features that suddenly change
behavior from 2.4.28 to 2.4.29 or whatever (that's the opposite of what users
are looking for).
That's how PHP does it now... new features can go into x.y.0, and once that is
released (actually, once it's in beta stage), anything that is not a small fix
needs to wait for x.y+1.0 or x+1.0.0. Which is not a big deal because these
releases land every year now, like clockwork.
I have said this in the other thread that hasn't gotten much traction ("A new
release process?"). The PHP team was in the exact same spot as HTTPD a few
years ago. No substantial progress, stale branches, no light at the end of the
tunnel, and a lot of fighting.
A structured release process fixed all that.
David
