I'd like to have a clear picture whether this n.{odd} version can affect in a bad manner legacy projects.
  1. Windows - If I'm not mistaking, on Windows libapr.dll is installed locally within a project's directory (apache, subversion). Unless there's a libapr.dll installed in a common location (%windir%, %system32%, %whereever%) or set in the system's "known dlls" registry key, having another version of the file somewhere on the system will not mess with other instances of the library. So (as far as I can see, having a n.{odd} library here is not going to mess anything.
  2. Unices - Linux distros set libapr-1.so to be an (indirect) symlink to the real libapr-1.so.0.2.x and applications link to libapr-1.so (or libapr1.so.0). If someone wants to use the n.{odd} version to test stuff he can always link his app to the libapr-1.so.0.{odd} version. I don't see how apache2 or subversion suffer from the new model. They only have to link against libapr-1.so or libapr-1.so.0. Even more, libapr-1.so.0.{odd} can be prepackaged by distros (whatever reason they might have) and lie as /usr/lib/libapr- 1.so.0.{odd}. The default /usr/lib/libapr-1.so and /usr/lib/libapr-1.so.0 still link to the stable {even} release and no application gets to suffer.
If there is a system where such a build system would cause breakage please say so, I have no experience on other systems.

On 10/9/07, Justin Erenkrantz <justin@erenkrantz.com> wrote:
> 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.

Still usable, just link the distributed binaries to an {even} numbered libapr. In fact, if your project does not use any of the new {odd} features and uses only {odd}-1=={even} API it will work properly no mather which kind of apr is installed on the system.

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

This is directed at developers to let them get their hand dirty with some bleeding edge new apr features. It's an easier method of finding if a new API needs to be extended or is just plain wrong and needs to be scrapped. You use a certain {odd} version and write code for that exact one, but you mustn't expect that some features make it into a maintainable release. apr.apache.org can document this very thoroughly so no one has any expectations about it.

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

This is doable too :) but you'd complicate things with 1.3.0-dev snapshot1, 1.3.0-dev snapshot2, 1.3.0-dev snapshot3, etc. but it's a definite candidate from my POV.

> 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