apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brad Nicholes" <BNICHO...@novell.com>
Subject Re: Backport and release policy for APR and APR-UTIL...
Date Wed, 15 Dec 2004 23:40:50 GMT
  I stand corrected on versioning.  This was actually some of the
information that I was looking for and just missed somehow.  But I think
that this brings up another issue that I am still confused about.  

  We have already created a 1.0.x branch.  Does this mean that we are
going to be creating a lot more short-lived branches?  I assume that
when we go to 1.1 we will be creating a new branch and so forth with 1.2
etc.  I also don't see how we are separating incompatible patches from
compatible patches if everything is going into TRUNK and there is no
where to backport.  It seems like we should have created a 1.x branch
rather than a 1.0.x branch and backported from TRUNK to 1.x.  The
versioning rules don't change the fact that we don't have a way of
moving forward with a stable release branch vs. an unstable development
branch.  Even if we were going to roll 1.1 today, where would be get it
from?  I assume TRUNK already contains patches that are meant for 2.x
and not 1.x and since backporting to the 1.0.x branch doesn't seem to
make sense, what do we do?  What am I missing?



>>> "William A. Rowe, Jr." <wrowe@rowe-clan.net> Wednesday, December
15, 2004 3:53 PM >>>
At 04:31 PM 12/15/2004, Paul Querna wrote:
>Brad Nicholes wrote:
>>The reason why it's *not* silly is because of our release schedules.
Unless the APR project wants to do something completely different with
>>versioning, revision releases (1.0.1 to 1.0.2) are usually on the
>>of a few months.  Point releases (1.0.x to 1.2.x assuming even
>>releases) are usually on the order of years.  Major releases (1.x to
>>2.x) are on the order of "who knows when".  That has been the history
>>HTTPD and I don't see any reason why it wouldn't be the history for
>>as well.

I hope we -don't- try to model httpd.  A library such as apr
is substantially different than httpd. 

>>  Given that assumption, I don't want to wait a year for APR 1.2
>>to be released just to see a minor bug fixed.  I want it backported
>>1.0.x so that it gets released next month (or sooner).  Also using
>>as an example, HTTPD 2.2 will not be binary compatible with 2.0.  We
>>have already made sure of that with a magic number bump.  Therefore,
>>don't see why APR 1.2.x must be binary compatible with 1.0.x.

Because those are our versioning rules... please review them.
Although httpd can change it's rules to suit the project, those
who adopt the apr library have based their decisions on the rules
we had laid down and already voted on.

We absolutely cannot break binary compatibility until the next
major rev.  If that means that apr is 10.1.0 in two years, so
be it.

>I am thinking it might be a good idea todo a 1.1.0 release before

Or 2.0 - if we actually fix the alignment issues.

>Lets just do it.  Whats stopping a 1.1.0 release today?  I don't see
any big issues, so, someone needs to take charge as a release manager
and make it happen.

+1 if 1.1 includes new features, and STATUS showstoppers are closed.
<hint description="If you have a 1.1 issue, add it to STATUS" />


View raw message