Re: Version bump policies and beta packages in stable branch

On Sun, Jan 25, 2004 at 11:40:51PM +0100, Frantz Dhin wrote:
> I have a request, and that is that configuration of such tree-specified
> defaults get separated from the other configuration options. It would be
> best to provide a conf file that can be freely tampered with by user, and a
> number of other files where the typical "If you edit this file you will void
> your support" statement is.

[...]

> So anyway that would mean at least 1 conf file per tree that user syncs up
> with and combines, so override policies and stuff like that would be in
> demand. Of course this still leaves the quirk for people who never ever wish
> to move from 4.0 to 4.1, but it somehow seems easier to reason with now. If
> the tree conf file is versioned like the xbuilds are, then a user can stay
> with a distribution version and never get untimely updates shoved in his
> face. 

Beautiful.  Another way to state this, is to separate a package's version
selection from the XBuilds, and even separate that selection from the
"release".  As a user, I want complete freedom to go backwards or forwards
in time, in relation to versions.

To do this, an XBuild file should never disappear, ever.  I should always
be able to emerge a specific version that I had before, that worked.

For example:

                            XBuild respository
              (holds every XBuild file ever released by Zynot)
                                      |
                   .------------------+-----------------------.
          Zynot Release 1.0           |               Zynot Release 1.1
     (conf file listing packages      |              (another conf file)
    and versions for Release 1.0)     |
                                      |
                   .------------------+----------------------.
       Stable Release Candidate                          Unstable
          (conf file again)                       (conf file... again :)
                                              this one would change regularly)


Now, as the user, I have a number of very handy options:
	- I can archive the entire XBuild repository locally
	- I can download only the XBuilds in my selected conf file to
		save space locally
	- I can pick the "release" conf file that I want to track
	- I can mix and match from all versions with my own conf file
	- I can go backwards in revision history if I find something
		that doesn't work (especially if tracking something in
		Unstable)
	- Upgrades and security fixes are done via conf files, conf file
		updates/merges, or versioned conf files. The updated
		conf file would just refer to the fixed XBuild files
		which can be found in the giant repositiory.
	- If the software supports it, I should be able to install a
		version from Release 1.0 and Unstable at the same time
		(especially for libraries)

Ideally, the tools would be able to take a snapshot of a given system's
package versions, creating a conf file that could be used to
go back to an entire "known good" system at any time.

With control like this, people would eagerly track Unstable and get more
testing for the entire system.

- Chris