On Mon, Feb 02, 2004 at 11:06:12PM +0100 or thereabouts, Spider wrote: > a) 4 / year , retention 1 year... > > can we start with 2/year (we lag behind as is, we're notoriously > ungood with timetables. See 1.4 release before vouching anything ;) and > a 2 year retention? 1 year retention still feels "hurried" for much > enterprise use. Especially if you spend 4 months with forking and > building on it, then have 8 months of use-work, then have to restart. > (yep, reallife scenario)
I feel it is important to align these release procedures with the rest of our release procedures. Since that is currently a quarterly release schedule, I'd prefer to keep this quarterly as well. > b) Updates and update distribution: > Updates should be distributed -separately- . once the tree is frozen > "stable" it remains so until the server goes down. updates to stable > builds should have an alternate path of exposure. This is another > requirement if any organization wish to track and work against a > distribution. > > supplying it as : > 2004-02-stable > 2004-02-updates I don't necessarily agree with this, but it's simple enough to provide a "2004.1-stable.tbz2" snapshot that people can use to have a totally unchanging tree. Then updates could continue to be distributed via the rsync mirror tree. --kurt
pgp00000.pgp
Description: PGP signature
