apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lucian Adrian Grijincu" <lucian.griji...@gmail.com>
Subject Re: [discuss] Adopt n.{odd} unstable release versioning?
Date Wed, 10 Oct 2007 23:05:06 GMT
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
>

--
Lucian

Mime
View raw message