On Thu, Jan 19, 2017 at 6:46 PM, Eric Covener <cove...@gmail.com> wrote:
> On Thu, Jan 19, 2017 at 4:43 PM, William A Rowe Jr <wr...@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.
>
> The "why" missing here is presumably to allow a 2.6 to be cut from
> trunk. But in that case, why not just fork it from 2.4 w/o a major nor
> magic cookie bump and let 2.4 become the more conservative stream?
Just so we are all in agreement, 2.4 has been neither conservative nor
maintenance in any conventional sense, for the past four years. Instead
we have users relying on the stable 2.2 release which we will discard
midyear, 4 1/2 years after 2.4 had shipped.
> New major/minor downstream releases can jump to 2.6 without much fuss,
> and current ones can try to track closer to current 2.4.x as they age.
What I'm proposing is that 2.6.0, 2.8.0, 2.10.0 (or we get out of odds/evens
at this point) are rapid feature releases, no less often than once a year.
For some arbitrary period, perhaps a year, fixes are applied to 2.prior.n+1
and yes, those can be tracked. Users can pick the .zero release to grab
the new features now, or wait for .1 or .2 to pick up any regression fixes.
But within two years, not four, 2.prior would be abandoned as 2.current
has been stabilizing (no features after .0) and 2.next (new features) is
about to be released.
This is closer to the model at most other ASF projects.
> We can find some new religion about how trunk work if some concise
> policy doc appears that we can all agree on.
That's the next step after concluding these dialogs, to weave together the
desires of the divergent committers' interests.
On Fri, Jan 20, 2017 at 3:09 AM, Stefan Eissing
<stefan.eiss...@greenbytes.de> wrote:
>
> Just some brainstorming:
>
> LTS/Stable/Feature branches
>
> 2.2.x/2.4.x/2.6.x for now
Note 2.2.x is not LTS. It is EOL July.
> 2.2.x/2.6.x/2.8.x if we think new features in 2.6 are stable and want to
> add more features
> 2.4.x/2.4.x/2.6.x if we end LTS for 2.2, the new LTS can be a stable branch
So 2.4.x again is implicitly unstable.
> 2.2.x/2.4.x/2.8.x in extreme cases, we could ditch a feature branch and
> move on.
Note that I'm suggesting *much* more frequent version minor releases.
I'd like to see us get *all* new features in users hands within 12
months of first commit.
Not the current pattern not those few which are backported and
destablizing to the
current release - vs those which are not backported, not tested, and
destablizing to
current vs. trunk repository contents.
I think it obviates the need for {even} {odd} if we move rapidly from
2.5.0-beta to
2.5.1-beta to 2.5.2-GA - branch trunk at 2.5.2-GA or 2.5.1-beta for
all new feature
work toward 2.6.0 and ensure 2.6.0-beta gets shipped in months, not a
half decade.
> - we continue working in trunk
> - backports to LTS/stable branches as now, review then commit
> - backports to feature branches: commit, then review
> - LTS is the support promise, stable/feature can move more freely
> - Feature is completely "experimental", we make no promises
> - Distros can support stable longer than we do, which is basically the model
> they are doing now for their LTS.
> - people will argue for more than 1 LTS release, but I think that is too much
> for the project, more something for a commercial undertaking
Note I'm suggesting that 2.current and 2.prior get fixes. We can leave the
hassle of backporting further than that to commercial or other endeavors, there
should be no point in time where the choice between those two is worse than
staying back at 2.ancient.
Note I'm suggesting that feature is 2.5.0-beta, 2.5.1-beta, right up until we
declare 2.5.x-GA. That release no longer gets enhancement/features, but
at that point we already have 2.6.0-beta trunk to keep bringing in the new
features.
This might look midyear like;
2.2.x - end of life, abandoned
2.4.x-GA - stable legacy
2.5.2-GA - stable (following a 2.5.0-beta & 2.5.1-beta of features/enhancements)
trunk - not released yet, but promised a 2.6.0-beta release within months
At that point we have three to maintain at a time, future, current, and one
immediately past branch. Not so different from what we have now, except
that 2.5.x isn't going through the churn 2.4.x did, while 2.6.x dev is ensured
to be a beta very soon if we agree we are collecting these features in trunk
with an actual assurance that it really will be released on an annual basis
if not even more frequently.
Amusingly, the docs for 2.5.7 will be the same docs as for 2.5.2, if the goal
posts no longer keep running up and back down the field. Much of the docs
groups effort to have 2.6.0 documented when we release won't have to be
backported at all.
> (and there could be odd version numbers in there as well, but does not matter
> to me)
I agree we should discard odd/even convention, if the accepted 2.5.x-beta
is adopted as GA.
>> 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.
>
> Is there a (remarkable) inability to ship new features today? Somehow
> simultaneously with too many new features shipping in 2.4.x? I'm not
> following this part.
There is no inability to ship new features today, there is an inability to keep
the current release anywhere approaching stable. The only stable branch
from a user's perspective is 2.2 which is absurd.
If we take a hard line on stable branch enhancements, there becomes
frustration if minor releases to include those features aren't forthcoming.
So the default operating mode of httpd has been to shoehorn every new
feature into the next subversion release, because otherwise your new
feature might be waiting four years to see daylight.
