apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: [discuss] Adopt n.{odd} unstable release versioning?
Date Tue, 09 Oct 2007 18:22:12 GMT
Justin Erenkrantz wrote:
> On Oct 9, 2007 11:02 AM, William A. Rowe, Jr. <wrowe@rowe-clan.net> wrote:
>> Justin Erenkrantz wrote:
>>> On Oct 9, 2007 10:48 AM, William A. Rowe, Jr. <wrowe@rowe-clan.net> wrote:
>>>>  [X] retain versioning as-is, e.g. 1.3.0 is our next potential 'GA release'
>>> If we have API-incompatible changes, then start the 2.x.x process -
>>> but us distributing 1.x.x with in-flux APIs is insane.  -- justin
>> One can argue bopping from 2.x.x to 3.x.x. to 4.x.x is much more asinine, as
>> it would give API users no possibility of settling on a supported version
>> with major releases every 6 to 12 months for API-breaking changes.
> Then change the versioning rules for 2.x.x.  But, changing the rules
> for 1.x.x after they've been codified for years *is* insane.  (FWIW, I
> disagree that we have to cut releases to get developer feedback.)  --

It isn't a change to /released/ rules, and it isn't a change to general
availability releases.

The only apparent change to the end-user is that there would be no 1.3.x,
and the next release they are told to obtain is 1.4.x or later.

Under the proposed change, ALL 1.3.x releases would be initially alpha,
and then beta, and then - it would die, 1.4.0 would carry on as the 'release'
and follow every versioning rule.

FWIW ONLY THE 1.3.x changes would be mutable in 1.3.x!!!

You could NOT change APIs introduced in 1.2.0 or prior, in case that point
has been missed.


View raw message