httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Zuelke ...@heroku.com>
Subject Re: Reset out x.minor.z definition of 'minor' at httpd?
Date Fri, 20 Jan 2017 00:12:08 GMT
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.


> On 19.01.2017, at 22:43, William A Rowe Jr <wrowe@rowe-clan.net> wrote:
> 
> I think one of our disconnects with 2.4 -> 2.6 is that in any other
> framework, there would be no ABI breakage in 2.6. That breakage
> would be deferred to and shipped as 3.0.
> 
> The httpd project choose to call 2.minor releases as breaking
> changes. Due to poor design choices, or frequent refactorings,
> this essentially shifted our release numbering schema down one
> digit. So 2.6.0 is not an enhancement release, but a major release
> in the general understanding of these things. This might be the root
> of Jim's and my failure to come to any consensus.
> 
> Right now, there are a number of gratuitous breaking changes on trunk
> that change binary ABI. I'm considering a trunk fork to preserve these
> changes (branches/3.x-future/?) and reverting every change to trunk/
> which was otherwise a no-op. Namespace, decoration, anything that
> prevents a user from loading a 2.4.x module in 2.next. And then we
> can look at what is a valid reason to take us to 3.0.
> 
> There might be some minor breakage that requires a recompilation,
> such as a user module allocating a req_rec. That is solved by setting
> a showstopper to the 2.next release to introduce _create() accessors
> to every structure belonging to the httpd API.  There would be side
> determinations... would we institute such a  change with the release
> of 2.5, or 2.6, or 3.0?
> 
> Once this is complete, binary breaking ABI changes would live in
> their own feature development forks. They would never be folded
> into trunk until there was a group consensus to push forward to
> version next.0.0 in the immediate future. trunk/ would cease to be
> a sandbox of ideas unready for release.
> 
> It's likely a couple-week process that I can't start till the end of next
> week. But I think the frustration about not being able to ship new
> features has a lot to do with our history of breaking API's every time
> we ticked up the version minor number.
> 
> It might be that we won't end up shipping 2.6 because other good
> and necessary binary-breaking-changes occur between now and
> in the near future, or that these exist on trunk. But if we defer the
> gruntwork of renaming things and whitespace mop-up etc until
> a short several-week period prior to the actual major.0.0 release,
> then we can keep trunk/ in a much more releasable state for all
> the new features.
> 
> We may have the impetus for a 3.0 release in the near future, we
> may not, but I'm sure the idea that 2.5 is a 'major' ABI-breaking
> release is not serving us well.


Mime
View raw message