Re: Versioning policy was Re: [PATCH] fix apr-config with symlinks

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

At 06:00 PM 3/30/2003, Justin Erenkrantz wrote:

>IIRC, there was some sentiment to burn every other minor patch number until we hit 1.0.  So, there would be no 0.9.2 only 0.9.2-dev and 0.9.3.  I'm very uncomfortable with such a scenario (what's the point of -dev then?).  It just doesn't make a lot of sense to me.  The -dev's should just not be released.
>
>Once we hit 1.0, the versioning rules should be in full force.  Is there any dispute over that?  -- justin

No... I like the every-other thought.  I'd go odds-devel/evens-release.

Bill

Re: Versioning policy was Re: [PATCH] fix apr-config with symlinks

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

At 07:42 PM 3/30/2003, Justin Erenkrantz wrote:
>--On Sunday, March 30, 2003 7:31 PM -0600 "William A. Rowe, Jr." <wr...@rowe-clan.net> wrote:
>
>>No... I like the every-other thought.  I'd go odds-devel/evens-release.
>
>And, what exactly is a odds-devel release?
>
>To clarify, what has been suggested for the odds/even policy is this:
>
>1.0.0: <initial>
>1.0.1: <devel>
>1.0.2: <release>
>1.0.3: <devel>
>1.0.4: <release>
>
>No statement on how compatibility is achieved in this model.

No, it's described below, but yes - the above is my ideal.

>The documented versioning policy we have says:
>
>1.0.0: <initial>
>1.0.1: <binary compatible with 1.0.0>
>1.0.2: <binary compatible with 1.0.0>
>1.1.0: <source compatible, but not binary compatible>
>2.0.0: <not compatible at all with prior releases>
>
>For a library, I like the last system by far.  -- justin 

It isn't contradictory, n.n.0 would be an initial drop, n.n.{odd} would be
the dev builds between qualified n.n.{even} releases.

Compatibility rules above would hold, and I don't even see a reason to
enforce httpd's 1.1 -> dev.  I don't see this library changing so much on
the main branch.  If I'm wrong, maybe we should consider this too, that
1.{odd}.* are all work-in-progress and don't follow the compat rules except
as applies to the prior 1.{even}.* releases.

Bill 

Re: Versioning policy was Re: [PATCH] fix apr-config with symlinks

[David Reid <dr...@jetnet.co.uk>]

Last one gets my vote. whichever we go for it needs to be CLEARLY documented
:)

david

----- Original Message -----
From: "Justin Erenkrantz" <ju...@erenkrantz.com>
To: "William A. Rowe, Jr." <wr...@rowe-clan.net>
Cc: <de...@apr.apache.org>
Sent: Monday, March 31, 2003 2:42 AM
Subject: Re: Versioning policy was Re: [PATCH] fix apr-config with symlinks


> --On Sunday, March 30, 2003 7:31 PM -0600 "William A. Rowe, Jr."
> <wr...@rowe-clan.net> wrote:
>
> > No... I like the every-other thought.  I'd go odds-devel/evens-release.
>
> And, what exactly is a odds-devel release?
>
> To clarify, what has been suggested for the odds/even policy is this:
>
> 1.0.0: <initial>
> 1.0.1: <devel>
> 1.0.2: <release>
> 1.0.3: <devel>
> 1.0.4: <release>
>
> No statement on how compatibility is achieved in this model.
>
> Or, do you mean something closer to httpd:
>
> 1.0.0: <initial>
> 1.0.1: <binary compatible>
> 1.1.0: <devel - not compatible with 1.0>
> 1.1.1: <binary compatible with 1.1.0>
> 1.2.0: <release - not compatible with 1.1>
> 1.2.1: <binary compatible with 1.2.0>
> ...
>
> The documented versioning policy we have says:
>
> 1.0.0: <initial>
> 1.0.1: <binary compatible with 1.0.0>
> 1.0.2: <binary compatible with 1.0.0>
> 1.1.0: <source compatible, but not binary compatible>
> 2.0.0: <not compatible at all with prior releases>
>
> For a library, I like the last system by far.  -- justin
>

Re: Versioning policy was Re: [PATCH] fix apr-config with symlinks

[Justin Erenkrantz <ju...@erenkrantz.com>]

--On Sunday, March 30, 2003 7:31 PM -0600 "William A. Rowe, Jr." 
<wr...@rowe-clan.net> wrote:

> No... I like the every-other thought.  I'd go odds-devel/evens-release.

And, what exactly is a odds-devel release?

To clarify, what has been suggested for the odds/even policy is this:

1.0.0: <initial>
1.0.1: <devel>
1.0.2: <release>
1.0.3: <devel>
1.0.4: <release>

No statement on how compatibility is achieved in this model.

Or, do you mean something closer to httpd:

1.0.0: <initial>
1.0.1: <binary compatible>
1.1.0: <devel - not compatible with 1.0>
1.1.1: <binary compatible with 1.1.0>
1.2.0: <release - not compatible with 1.1>
1.2.1: <binary compatible with 1.2.0>
...

The documented versioning policy we have says:

1.0.0: <initial>
1.0.1: <binary compatible with 1.0.0>
1.0.2: <binary compatible with 1.0.0>
1.1.0: <source compatible, but not binary compatible>
2.0.0: <not compatible at all with prior releases>

For a library, I like the last system by far.  -- justin