At 04:50 PM 12/16/2004, Brad Nicholes wrote:
> I must still be missing something because this just seems really
>unorganized and confusing. If the above is true, then when 1.x finally
>does branch and TRUNK becomes 2.x, we will have a 1.0.x branch, 1.1.x
>branch ... 1.xxx.x at the same level as
On Thu, Dec 16, 2004 at 03:50:44PM -0700, Brad Nicholes wrote:
>So if I understand this correctly, the policy for APR is to simply
> put all code changes into TRUNK and each release should bump the minor
> version number and create a new branch.
Yes.
> The only time that there is a patch re
So if I understand this correctly, the policy for APR is to simply
put all code changes into TRUNK and each release should bump the minor
version number and create a new branch. The only time that there is a
patch release is if there is some critical reason for it which in this
case would cause
--On Wednesday, December 15, 2004 4:40 PM -0700 Brad Nicholes
<[EMAIL PROTECTED]> wrote:
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
Yes.
when we go to 1.1 we will be creating a new branch and so forth
Brad Nicholes wrote:
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
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
On Wed, Dec 15, 2004 at 01:29:02PM -0500, Cliff Woolley wrote:
> On Wed, 15 Dec 2004, Brad Nicholes wrote:
>
> > release of APR 1.0. Since then there has been a lot of activity in
> > TRUNK as compared to almost no activity in the 1.0.x branch.
>
> After the 1.0.x branch was created at ApacheCon
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 order
>>of a few m
Brad Nicholes wrote:
That's understandable. But asking about backporting from 1.1.x
to 1.0.x seems somewhat silly.
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
>That's understandable. But asking about backporting from 1.1.x
>to 1.0.x seems somewhat silly.
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 o
Ok, you have me confused :) There can be no binary breakage
between 1.0.0 and 1.99.999. Nothing (except for unreleased
changes in our svn repository) as we move forward.
Minor bumps introduce new features. Subversion bumps fix bugs.
That's the short story.
I'm increasing concerned that folks b
Where all of the backports included in the CHANGES file for version
1.0.1? What about any work that has been done since 1.0.1? There still
aren't sections in the STATUS files for listing and voting on backports
and I just recently added a "Changes for APR 1.0.2" in the APR changes
file because
On Wed, 15 Dec 2004, Brad Nicholes wrote:
> release of APR 1.0. Since then there has been a lot of activity in
> TRUNK as compared to almost no activity in the 1.0.x branch.
After the 1.0.x branch was created at ApacheCon, Justin and Thom
backported everything that they thought could be backport
What is the backport and release policy for APR and APR-UTIL? I
assume that the APR and APR-UTIL projects have adopted the same
"RTC/STATUS file voting" policy as the HTTPD project. Assuming that
this is true, there appears to be a break down in how this policy
functions in the AP
14 matches
Mail list logo
