[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <418B4556.3070903@op5.se>
Date: Fri, 05 Nov 2004 10:18:14 +0100
From: Andreas Ericsson <ae@....se>
To: owl-users@...ts.openwall.com
Subject: Re: Owl-current moved to glibc 2.3.x
Solar Designer wrote:
> On Wed, Nov 03, 2004 at 01:41:08PM +0100, Andreas Ericsson wrote:
>
>>The previous versions of current (prior to "The Big Update") has been
>>very stable on about 80 production critical servers for us. How about
>>naming the 'current' prior to "The Big Update" Owl 1.2-stable (or 1.1.1
>>stable or whatever),
>
>
> Yes, I had this thought, too. But to do it right, we'd have to make a
> 1.2 release and that's quite some work (build/test on all archs, build
> an ISO image of the latest, propagate it to CD production). Then we'd
> maintain a 1.2-stable instead of 1.1-stable.
>
I can build and test it on i386, but I haven't got the kind of access
needed to build everything on any other platform.
> If, however, we make a 1.2-stable without a 1.2 release, I don't feel
> we'd have the right to abandon 1.1-stable like that. And maintaining
> three branches at once (1.1-stable, 1.2-stable, and current) would be
> too much overhead.
>
1.1 and 1.2 would be binary compatible, so 1.1 could possibly be dropped
from maintenance in favor of 1.2. Are there any strong suggestions
against this?
> Now, there's the option to simply roll all updates from current prior
> to the Big Update into 1.1-stable, but there's one change some might
> not appreciate despite the system remaining very stable: the Perl
> version change (5.6.x to 5.8.x). This will break support for Perl
> modules people have built locally. Not something to be done within a
> stable branch.
>
Hadn't thought of that, but I think sensible users can choose not to
upgrade perl if they rely to heavily on extra modules they've built, or
simply build them again for perl 5.8. Besides, I'm sure a lot of people
were running current as it was before the big update and has already
upgraded their perl packages so the problem with perl is double-edged.
>
>>Optionally, put the 1.1 binary compatible updates in 1.1_updates and
>>stick with current for everything new, including the biggies, before
>>bumping the release for that one.
>
>
> I don't quite understand this suggestion.
>
Just keep updates for 1.1 in a separate directory. This way users can
pick what updates they would like to install, but there would be no need
to drop what's currently the most recent version of 1.1 binary
compatible packages, or jumble them together with packages post-biggie.
--
Andreas Ericsson andreas.ericsson@....se
OP5 AB www.op5.se
Lead Developer
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
