[ros-kernel] Release process

[Vizzini]

On Sun, 2003-10-12 at 03:42, Ge van Geldorp wrote:
> - It's not clear to me who's responsible for getting changes made in the
> branch back into HEAD. In Vizinni's message "CVS Branching Proposal" of
> 2 Sept the proposal is: "Any commits on a branch must be merged into
> HEAD by the committer". Then, Casper said on 5 Oct in a "Re: CVS Update:
> reactos" message: "Don't fix it on both branches since CVS cannot track
> what has been merged and what has not been merged". Either way works for
> me, we just need to make a decision on it.

For this time, I can see if there is any merging to be done.  In
general, though, I would recommend that each developer who commits to
the release branch also merge that change from release to HEAD. 
Reasons:

 - This prevents somebody from having to understand each patch,
including whether or not it should be merged at all
 - These commits should be small and rare, in general, so this shouldn't
be terribly inconvenient

At the end of the process (i.e. now) someody (me? jason? someone else?)
should go through CVS and merge anything that was missed.

Perhaps if people could put something in the commit messages on the
branch if the chanage should *not* be carried over to HEAD, that would
make the job easier.

> 
> - Maybe we should put out a RC1 (Release Candidate) .iso at the
> beginning of the feature freeze and a RC2 at the beginning of the code
> freeze. Testers are not always developers and may have problems
> building. Maybe by providing the .iso's more people would be willing to
> test. More testers are needed in the future as we are moving slowly to
> supporting third-party drivers.

Great idea.  I still think that getting involved in development and
testing are too difficult at the moment, so I'm in favor of anything
that eases the pain.  Also, I think it's a great idea for the release
engineer to get some practice with a given branch, just in case there
are oddities.

> - I would like to see a small change in the version numbering. At the
> moment we have e.g. 0.1.4.3, with the ".3" meaning it was build on the
> 3rd day after the 0.1.4 release. I think this is a bit meaningless and
> would like to propose 0.1.5-CVS for any past-0.1.4 build from HEAD,
> 0.1.5-RC1/0.1.5-RC2 for the next Release Candidates and plain 0.1.5 for
> the next final release. Some changes will have to be made to our build
> system for this, I volunteer to do that if this proposal is accepted.

I have no problem with this proposal, and I agree that the
day-as-version system is pretty meaningless.  If we do nightly code
snapshots and/or builds, we may want to use date versions, though, but
in that case we'd  use an absolute date rather than a relative one (i
think?).

 -Vizzini