info-cvs
[Top][All Lists]
Advanced

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

Re: release management with CVS


From: Kaz Kylheku
Subject: Re: release management with CVS
Date: Thu, 13 Sep 2001 17:51:13 GMT
User-agent: slrn/0.9.6.3 (Linux)

In article <address@hidden>, Muhammad Shakeel wrote:
>Dear all,
>
>For version control we had started using cvs. I could not find much more
>for release management in cvs. Please guide for  release management,
>while using cvs what are the tools ?

Release management consists of following some processes. You have to
understand these processes independently of CVS, and then apply your
understanding of the mechanisms of CVS to implement these processes
in a concrete way.

Start with these principles: every formal build of the software should
be tagged. It should be possible to retrieve any past tagged build
from the repository and recreate it exactly. Each build must be made
from a tagged baseline of the objects in the repository.

Once you have a sane build process, you can think about releases.
A release is some stable version of software offered to people other
than developers and testers. A release will be based on some build that
is identified as stable: it is in good shape quality-wise and does not
need any more features. This is called the release candidate build.
That build is then released to a broader audience than just developers
and testers; it is a beta test release. Based on the feedback, several
more builds may have to be made to fix some bugs. If development of
new features needs to proceed concurrently with this final bugfixing,
then a branch is made which stems from the candidate build; the fixes are
done on that branch, and the ultimate release will be a formal build on
that branch (and of course, any changes on that branch are merged
to the development stream). Alternately, if the developers have nothing
other to do than to stabilize the beta and ship, then the final fixing can
proceed in the same line, with the understanding that only critical fixes
are to take place (so-called ``code freeze''). Once you have released,
you continue developing, and the release cycle repeats itself.

If your code is in great shape, you will never need to make a branch from
the candidate build, because it will be good enough to be acceptable to
the users.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]