You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2007/10/09 20:02:07 UTC
[discuss] Adopt n.{odd} unstable release versioning?
Justin Erenkrantz wrote:
> On Oct 9, 2007 10:48 AM, William A. Rowe, Jr. <wr...@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.
Re: [discuss] Adopt n.{odd} unstable release versioning?
Posted by Tollef Fog Heen <tf...@err.no>.
* "Lucian Adrian Grijincu"
| 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.
Except that linking is done with the SONAME in the .so:
: tfheen@xoog /tmp/test > cat test.c
int main() {
return 0;
}
: tfheen@xoog /tmp/test > gcc -o test test.c -L. -lfoo
: tfheen@xoog /tmp/test > objdump -x test | grep NEEDED
NEEDED libapr-1.so.0
NEEDED libc.so.6
(libfoo.so in the current directory is just a copy of libapr-1.so.0.2.7)
If you really, really want to avoid people ending up with wrongly
linked binaries, make the SONAME libapr-1.so.$svn-revision and then
make it .0 for releases. Anybody shipping anything linked with a
snapshot will then have very visible breakage when they try to use the
binary if they don't have all depends installed.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
Re: [discuss] Adopt n.{odd} unstable release versioning?
Posted by Lucian Adrian Grijincu <lu...@gmail.com>.
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 <ju...@erenkrantz.com> wrote:
> On Oct 9, 2007 11:22 AM, William A. Rowe, Jr. <wr...@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
Re: [discuss] Adopt n.{odd} unstable release versioning?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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
includes.]
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.
lib_module_noun_verb
how hard is that anyways?
Bill
Re: [discuss] Adopt n.{odd} unstable release versioning?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Oct 9, 2007 11:22 AM, William A. Rowe, Jr. <wr...@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
Re: [discuss] Adopt n.{odd} unstable release versioning?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Justin Erenkrantz wrote:
> On Oct 9, 2007 11:02 AM, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
>> Justin Erenkrantz wrote:
>>> On Oct 9, 2007 10:48 AM, William A. Rowe, Jr. <wr...@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.
Bill
Re: [discuss] Adopt n.{odd} unstable release versioning?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Oct 9, 2007 11:02 AM, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> Justin Erenkrantz wrote:
> > On Oct 9, 2007 10:48 AM, William A. Rowe, Jr. <wr...@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.) --
justin