Re: The state of the heimdal project

[Harald Barth <haba@pdc.kth.se>]

> > Goal: 0.8. Here is a heimdal-0.8rc1.tar.gz. 0.8 will be due 20061031.
> > Test and report back until that date, or 0.8 will be as good/bad as
> > 0.8rc1.
> 
> But until all things that is on my list of putting into 0.8, what the  
> point ?

You did ask what's the point of going forward with 0.8 until all
things that are on your list which should go into 0.8 are done?

0.8 was just an example. Say 0.7.3 or whatever.

It really does not matter so much what features or bugfixes are on the
list of the programmer. The release manager sets a date. What is done
until that date is in release X. The rest will be in release X+1 or
X+2. If releases are scheduled regularely it is not so bad to wait
some extra month. The desperate ones can run snapshots anyway, can't
they? That way you get predictable release cycles towards the
packagers for distros. If you wait too long between releases,
the world (even known as OS releases) has changed very much and
the project will have a hard time to catch up the big step the
world has evolved.

> And what is diffrent in this compared to how I do this today ?

> http://www.stacken.kth.se/lists/heimdal-discuss/2005-08/msg00022.html

1. Announce the next release date much earlier, say 1/2 year in advance.

2. Make time between rc1 and release date longer that "in the beginning
of next week". It will take approx a month (it did).

3. Keep the announced release date. Rather cut the feature list than
miss the release date. The exception to the rule is of course
showstopper security bugfixes/releases.

> 0.7.2 was a security release, I can't announce in public for testing  
> so I did it privately.

True.

Harald.

PS: This is just dumped from my head, if there are any insightful sites
    about release management on this Internet you know about, either
    for or against my theories, feel free to fill in.