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.