Most likely 1.3 1st then 2.x

[Jim Jagielski <ji...@jaguNET.com>]

To be honest, I can't see holding off the 1.3 release any longer
while we're waiting on APR as well as stuff is being added
to the 2.x trees... It's kind of embarrassing.

So even though I have most of the files setup for triple
release, I think next week I'll just release 1.3 and we
can the release 2.x when ready and not continue to hold
our 1.3 users hostage.

Re: Most likely 1.3 1st then 2.x

[Jim Jagielski <ji...@jaguNET.com>]

On Aug 24, 2007, at 7:47 PM, Sander Temme wrote:

> Ruediger Pluem wrote:
>
>> On 08/24/2007 02:54 PM, Jim Jagielski wrote:
>>> To be honest, I can't see holding off the 1.3 release any longer
>>> while we're waiting on APR as well as stuff is being added
>>> to the 2.x trees... It's kind of embarrassing.
>
> +1.
>
>> As far as I understand this "downgrade" scenario is one of the  
>> reasons
>> why we aim to release all stable branches at the same point of time.
>
> It might help to keep the release quiet: put the code out there and
> update the page, but keep it off the front page and out of the public
> channels.
>
> We can even do the same for 2.0.x once we have our regression  
> fixed, and
> then make a splash for all three when 2.2.x is done.
>

This is all well and good, except, to be honest, how confident
are we that 2.x will be released any time soon? If they
were, I'd say wait and release/announce all 3 together.

We've pushed back the releases at least 3 times already;
1.3 is ready; 2.0 and 2.2 aren't, yet, and we have no
real idea when then will be. Like I said, I can't
see keeping 1.3.38 from our 1.3 users simply because
2.x isn't ready....

Re: Most likely 1.3 1st then 2.x

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

Sander Temme wrote:
> 
> We can even do the same for 2.0.x once we have our regression fixed, and
> then make a splash for all three when 2.2.x is done.

2.0 and 2.2 both have piped log issues.

For 2.0 this is slightly more critical, we still invoke the log pipe app
directly, and then pid_kill the thing on plog teardown.  This means
there is a lag between now-dead logger and new open_logs hook, which
is especially uncool.  On 2.2 it's not quite so bad, since we pid_kill
bin/sh leaving bin/sh's invoked process running.

r569535 doesn't quite clean on either 2.0 or 2.2, so I'll post up the link
a bit later to tweaked patches.

Re: Most likely 1.3 1st then 2.x

[Sander Temme <sc...@apache.org>]

Ruediger Pluem wrote:

> On 08/24/2007 02:54 PM, Jim Jagielski wrote:
>> To be honest, I can't see holding off the 1.3 release any longer
>> while we're waiting on APR as well as stuff is being added
>> to the 2.x trees... It's kind of embarrassing.

+1.

> As far as I understand this "downgrade" scenario is one of the reasons
> why we aim to release all stable branches at the same point of time.

It might help to keep the release quiet: put the code out there and
update the page, but keep it off the front page and out of the public
channels.

We can even do the same for 2.0.x once we have our regression fixed, and
then make a splash for all three when 2.2.x is done.

S.

Re: Most likely 1.3 1st then 2.x

[Ruediger Pluem <rp...@apache.org>]

On 08/24/2007 02:54 PM, Jim Jagielski wrote:
> 
> To be honest, I can't see holding off the 1.3 release any longer
> while we're waiting on APR as well as stuff is being added
> to the 2.x trees... It's kind of embarrassing.
> 
> So even though I have most of the files setup for triple
> release, I think next week I'll just release 1.3 and we
> can the release 2.x when ready and not continue to hold
> our 1.3 users hostage.

+1. I think the number of people going back to 1.3 from 2.0 / 2.2
because this 1.3 release is "newer" than the latest 2.0 / 2.2 release
is comparable low.
As far as I understand this "downgrade" scenario is one of the reasons
why we aim to release all stable branches at the same point of time.

Regards

Rüdiger