apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Justin Erenkrantz" <jus...@erenkrantz.com>
Subject Re: [discuss] Adopt n.{odd} unstable release versioning?
Date Tue, 09 Oct 2007 18:39:02 GMT
On Oct 9, 2007 11:22 AM, William A. Rowe, Jr. <wrowe@rowe-clan.net> wrote:
> It isn't a change to /released/ rules, and it isn't a change to general
> availability releases.

No, it is.

> 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.

The problem is that all of the downstream users have to change their
own compatibility rules to adjust for us reneging on our release
policies.  Serf and Subversion would have to be substantially tweaked
to adjust for this as all of APR's versioning policies get thrown out
the window as the version tag is no longer usable.

> 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.

Nope.  There is simply no semantic to be able to enforce "odd"
versions are incompatible at run-time.  We rely upon library
versioning semantics to deal with this.

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

I don't think you fully appreciate what impact this change has on
consumers of APR.

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

I don't understand the fixation to keeping the 1.x.y semantics if you
are so intent on busting the versioning rules.  But, I absolutely
don't think it's fair to change the rules mid-stream.

Either release a 1.3.0-dev snapshot or move trunk to 2.0.0-dev if you
think the APIs change substantially and need feedback.  However, in my
opinion, under no circumstances should we *ever* release a 1.3.1 that
isn't compatible with 1.3.0 per the current versioning rules.  We
committed to those rules and we need to stick to them.  The only
avenue for changing them is when we go to 2.0 - and even then, I'm not
sure I'd support such a change anyway; but at least then, we could
entertain that discussion.  -- justin

View raw message