[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: New Markets



Rick Macdonald:
> 1.3/
> stable/
> unstable/

This is also how I would try to do it, more or less.  With the three
month cycle Bruce mentioned -- which sounds like a suitable pace --
I'd allocate two months for anything-goes updates, and one month for
bug-fixes-only updates.  After three months, you should have an improved,
but stable system that can be released.  The directory structure might
be:

	1.1/
	unstable/
	
All updates go to unstable.  When a release is finished, you do

	cp -r unstable 1.2
	
(or "mv unstable 1.2" and then build a new unstable with symlinks into 
the latest release).

There may be a need to fix things before the next three-monthly release.
For this, add a fixes directory:

	1.1
	1.1-fixes
	unstable/
	
This does mean that people have to download both 1.1 and 1.1-fixes, but
I think it is important to not change 1.1 after it has been released,
not even to add fixes.  Keep the fixes separate.  Hopefully there won't
be too many of them in three months.  People who download via FTP shouldn't
have too much trouble going to those two directories.  On the other hand,
if they do, a 1.1-with-fixes directory could be added.

I haven't ever done proper release engineering.  You probably shouldn't
be listening to what I say.

> Alternatively, there wouldn't be a "stable"; only "unstable" which would be
> "the-next-release-in-waiting". This doesn't seem as smooth though.

It works for the kernel.  It keeps things simpler.




Reply to: