Stable / Testing / Bleeding, forked from #zynot-dev

[email protected] Mon, 1 Sep 2003 09:09:25 +1000
Newsgroups gmane.linux.zynot.devel
Message-ID <[email protected]>
The following is relevent to the discussion on stable/bleeding/testing
that took place on #zynot-dev, it is my two cents on the ideas and 
suggestions (with a few of my own)...

Would it be wise to perhaps concurrently run three versions, 
v1, v2, v3 where v1 contains the stable base system of binaries that 
only gets updated when moving to say v1.1 etc, v1 would also have futher
ebuild supplied stable packages in two trees such that one could emerge 
packagename, which will fetch a stable binary because of the "binary" 
version you are using, and have an emerge flag, eg --build-from-source 
which builds that package how you want from source, these source builds 
will have to have their own profile such that updates from v1.0 -> v1.1 
rebuilds them from source... 

v2.0 does not supply binaries by default, but can use the v1 binaries 
if emerge --with-binary or similar is specified. v2 could also include 
testing packages, so that if someone wants a newer package for features 
they can openly install it, these will need their own profile similar 
to the source builds in v1, a bump to v2.0 -> v2.1 would infer that a 
large number of the "testing" builds are now considered stable, this 
would have to be developer decision, note that the packages arent marked 
stable individuallly on the way, they are marked together once the system 
as a whole is found to be stable with them all.... 

v3 should consist of both the v1 and v2 profiles but should by default 
use the testing from source builds, unless explicitly stated, v3 should 
also include cvs/svn ebuilds so that the testers can bleed if they wish 
this versions updates v3.0 -> v3.1 would probably be similar to the v2 
method... 

when we get to v1.9 that is the end of version one, the stable version 
becomes version two because by then it has all stable from source builds 
etc... version three becomes the stable/testing tree and version four 
(new) becomes the testing/bleeding tree.

This method allows for a binary based stable install which can be build 
upon by anything from stable to bleeding binaries or source, and also 
allows for a cvs everything machine that runs no released packages.

Andrew Bevitt.