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 Thu, 11 Oct 2007 07:29:49 GMT
Justin Erenkrantz wrote:
>> 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.

Now hold up.

Serf and Subversion would be VERY ILL ADVISED to ship based on the
floating target.  They too would be constrained to an alpha/beta.
In fact, I'd suggest that anyone trying this would want to mark their
package as depending on exactly n.x.y.  Not on n.x minimum.  They too
would be alpha/beta if they relied on a alpha/beta apr.

[And I really liked Lucian's point, especially if we were to cripple
make install to NEVER NEVER deploy the apr-n.so symlink!  But that
is another issue to consider altogether, also have the issue of

The only sane prerequisite would be 1.2...  or 1.4.  None of this
'maybe something from 1.3.2 fowards'.  No - if it's using a feature
of 1.3, they need to release for 1.4.0 forwards.  (Of course we would
be breaking it to their desire until 1.4.0 is blessed.)

So your argument doesn't hold water, you need to be more specific.

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

I do.  People who adopt alpha/beta of such a library aren't end users,
or to the extent they are, no harm, no foul, because nothing is asking
for 1.3.2 minimum.

Yes we would need to clear this up in the versioning rules, but I'm
just not seeing a showstopper here.

> 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

We won't call it 2.0 for the sake of 'taking this for a whirl'.  But
we are getting close, I'm looking at some pretty crappy function names
these past few weeks.


how hard is that anyways?


View raw message