[prev in list] [next in list] [prev in thread] [next in thread] 

List:       annvix-dev
Subject:    Re: [dev] upgrade/update procedures
From:       Vincent Danen <vdanen () opensls ! org>
Date:       2004-06-10 4:14:47
Message-ID: B5C1641E-BA94-11D8-881F-000A9598BFB2 () opensls ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Jun 9, 2004, at 4:45 PM, Ying-Hung Chen wrote:

> 	Another general question, since the vision of opensls is not going to 
> be per releases basis. (The software will be upgrading continuesly) 
> How are the team envision this to be done?

The plan I had in mind was to have 1.0-CURRENT turn into 1.0-RELEASE, 
and then branching to 1.1-CURRENT.  One could continue to track 
CURRENT, or stick to a RELEASE (ie. like the *BSD's).  So you could 
install 1.0-RELEASE, when 1.1-RELEASE comes out, upgrade to it, etc.

When we're ready to move to the 2.6 kernel and a newer gcc/glibc/etc. 
we'll start a new branch and call it 2.0-CURRENT.  We'll try to 
maintain a clean upgrade path for 1.x to 2.x but some stuff may change 
(the major branches will be for big new features, such as new kernel, 
new glibc, etc... things that may make it incompatible to the previous 
major branch).

For instance, 1.x will always be the 2.4 kernel... 2.x will always be 
the 2.6 kernel.. 3.x may be the 2.6 kernel and a new major glibc and/or 
gcc change that is incompatible with older versions, etc.

In all cases, one should be able to do a urpmi --auto-select to do a 
full upgrade, even across major branches.  That's the goal, anyways.

-- 
OpenSLS - Secure Linux Server: http://opensls.org/
"lynx -source http://linsec.ca/vdanen.asc | gpg --import"
{FE6F2AFD : 88D8 0D23 8D4B 3407 5BD7  66F9 2043 D0E5 FE6F 2AFD}

["PGP.sig" (application/pgp-signature)]

_______________________________________________
dev mailing list
dev@opensls.org
http://opensls.org/mailman/listinfo/dev


[prev in list] [next in list] [prev in thread] [next in thread]