Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 05 Nov 2004 10:18:14 +0100
From: Andreas Ericsson <>
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         
OP5 AB                   
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.