apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: Showstopper ... was: Tagged the tree
Date Thu, 09 Jan 2003 21:43:52 GMT
On Thu, Jan 09, 2003 at 02:26:50PM -0600, William A. Rowe, Jr. wrote:
> We are waiting on only one thing for APR 1.0, the full set of versioning
> API functions.  I don't know where this stands, and I know Greg was
> full of ideas/designs.  I'd like to see some feedback on this.

The versioning mechanisms, functions, etc are all fully coded. They were
that way before I spun up the 0.9.0 release. The versioning document
outlines all of the human background for using that.

>...
> Yes, httpd-2.0 is/will be forever keyed to 0.9.

Right. So we need to create a branch in APR that httpd can use for
maintenance. APR is going to advance on its own schedule, so httpd needs to
pin to a specific revision and just go with that.

> We need to clear out all of
> the early design cruft going forward.  Quickly, so that authors adopting the
> httpd-2.1 model have the right declarations and none of the historic and now
> dead macros or stubs.

We get to clear it out at any point leading up to 1.0. That is exactly what
the rules state. We aren't doing it out of "niceness" for httpd. But before
a product is 1.0, it is free to do as it likes.

> Because 0.9, for a while, will inherit the renaming
> going on for 1.0, any 1.0 code that doesn't use new features can still be
> compiled (but won't be binary compatible) with 0.9 and httpd-2.0.

I don't follow that. (prolly doesn't matter tho, based on other parts of my
email)

> >>Committing the change was the breakage.  It violated -our-
> >>versioning rules. With the holidays, many eyes had been distracted
> >>elsewhere, so now we are just playing catch-up to catch invalid
> >>commits.
> >
> >No, it wasn't.  We've broken the API lots of times before in the 0.9.x series.  You
just want to enforce backwards-compatibility on APR when it isn't ready because a project
that uses APR requires backwards-compatibility.  Part of me says, "Tough."  httpd made a poor
decision relying upon a library that wasn't 1.0 with fixed version rules.
> 
> Quit it... we've been binary compatible for many successive httpd releases.

Happenstance. APR(UTIL) is free to change its API. You're missing that
point.

> In fact, the last binary breakage was the 'widening' of the error number ranges,
> and the poll change, which in hindsite I would have vetoed for later release
> in the APR 1.0.  No matter, that's done and we're moving forwards.
> 
> We've proven the 90/10 rule that few changes need to break binary compat.
> And we've tried to stick to it.  These changes we are discussing are minor, 
> gratuitous, and introduce breakage just for the sake of breaking compatibility.

No. *YOU* have tried to stick to it. The versioning rules don't support this
position. APR hasn't gone final, so it isn't bound to any contract.

> >IMHO, the proper thing to do is to branch off APR from where 2.0.43 went off, call
that API 1.0.  Apply relevant fixes as needed (bumping versions based on the version rules
- i.e. filepath_encoding bumps the minor).  Then, start on APR 2.0 with removal of deprecated
functions and we can change signatures as we like.  -- justin

Agreed. I'd state that we make the 0.9.x branch for httpd, and change the
HEAD to be 0.10.x. When we feel cozy, then we can pop to 1.0.

(altho, I would also suggest we spin the minor number for releases, rather
 than the patch level; i.e. release 0.10.0, then 0.11.0, then 0.12.0; if we
 need a quick patch, we can do 0.11.1 or somesuch)

> No, we agreed a long time ago that versioning must be complete and immutable
> before we call this APR 1.0.

The versioning system is, yes. The APIs are sufficient, along with the rules
to support them. I'm a bit leery of allowing new functions in minor releases
mixed in with how we construct our library names, but I think we'll see how
that pans out; we can always change how we name libraries.

> Versioning APIs and macros shouldn't be changed
> between 1.0, 2.0, 3.0 and so on, so let's take the time and get it right.

Nobody has suggested any chagne to the APIs or macros.

> Branch
> APR_0_9_BRANCH for maintenance alone,

For maintenance for httpd, yes.

> and move on with the final '1.0' rollout.

We'd move to 0.10.0-dev and march towards 1.0, yes.

> We are close, I agree.  But there is no reason for all of these deprecated
> 0.9 APIs to persist into 1.0, and there is no reason for httpd-2.0 to move onwards
> to 1.0

Agreed.

> (although you must be able to compile httpd-2.0 in either APR 0.9 or 1.0,
> the two builds are just not binary compatible.)

Nope. That jump in the major version implies an ability to break the source
compatibility. We cannot release APR with a broken API, thus the need to
allow changes to it.

> Because httpd-2.0 is trying to remain binary compatible, it needs to stay back
> on APR 0.9 for official binary releases.

Yup. I'm +1 on going "back" and create a branch for 0.9.x and key httpd to
that. People can backport changes to that branch.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message