|Main Archive Page > Month Archives > spamassassin-dev archives|
--On Thursday, September 15, 2011 1:13 PM -0400 firstname.lastname@example.org
> I've used several revision control systems. I've never maintained one
> myself, really. My previous related comment was just to allow, again, for
> the possibility that I missed something (a technical reason a svn branch
> couldn't be named "3.4.1" instead of "3.4"). Is there any particular
> aspect of RCS or release engineering that you would like me to read up on?
Here is a general overview of RCS and RE from my work on various projects
that I think applies. Note that I do not develop for SA or any other
Apache projects, and that they have very specific rules, but the discussion
on here indicates the basic principles are the same.
In a given RCS (svn, git, CVS, whatever), there is a branch that
development work is done in. This is generally referred to as "main",
"trunk", "mainline", or "master". There may be other less common names as
well. In addition to the "main" branch, there are also release branches
from which releases are cut. How release branches are organized can vary
from project to project, but they are generally organized in the same
method. More on this in a second.
The next thing to consider is versioning, as release branches are basically
created based on this. The majority of software programs use a three part
versioning system. For example with OpenLDAP, a release of "2.4.26" means
that it has a MAJOR version of 2, a MINOR version of 4, and a PATCH LEVEL
of 26. Or in other words, 2.4.26 is the 26th release of the 2.4 version of
OpenLDAP. For OpenLDAP, releases start versioning a 1. I note that SA
starts versioning at 0, so this is a minor but worthwhile difference to
Release branches in OpenLDAP (and most other software projects) are then
based off the MAJOR and MINOR versions. For example, there is a 2.0, 2.1,
2.2, 2.3, and 2.4 branch for OpenLDAP in addition to "main". The
discussion for SA here is similar. They have a 3.2 and 3.3 branch (and
plenty others I'm sure), and the discussion here is to create a 3.4 branch
for 3.4 releases.
Where this concerns development is in the following way:
New features, etc, are generally committed to the "main" branch. Depending
on the project, bug fixes are either committed to "main" and integrated
into the applicable release branch, or committed to the release branch and
integrated back into "main". It sounds like SA works in the former way.
I.e., C-T-R for trunk, and then R-T-C into the release branch.
This allows for fixes to be quickly available for testing, and then once
they are confirmed, they can easily be integrated into the release branch
for the next release.
New releases are cut from the given release branch, and that branch has a
TAG created for the release. This means you can easily "create" that
specific at any given time by using the TAG stored in the RCS. For
example, there is a 2.4.26 TAG in the OpenLDAP 2.4 release branch, so that
if someone wants to pull the release source directly from OpenLDAP's git
repository, they can do so quite easily (as opposed to them downloading it
from the OpenLDAP website in tarball form).
The entire point of all of this is to have clearly defined release
branches, with clearly defined releases that are isolated from potentially
destabilizing development that can be occurring in "main".
The context of the discussion on the SA side has been to create an official
3.4 release branch from "main", which is known to be extremely stable, so
that new releases (such as 3.4.0 and potentially 3.4.1, etc) can be cut
from it, and any new development for a next generation SA can be done on
"main" without the concern of potentially destabilizing the 3.4 release
Hope this helps!
-- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration