Re: Stable tag will be slipped Sunday and release engineering wi
:Okay, I am proud to claim the role of the least educated and the most amateurish
:of all DFly groupies, so I will ask the painfully stupid questions :o)
:
:I've been following the long and confusing thread about what the various tags
:should be named (and why) and I am hereby declaring my total confusion.
:
:I've been following FreeBSD-CURRENT for about ten years, and yet I still don't
:understand the meaning of their tag names -- so, should I be surprised that I
:don't understand the DFly names either?
:...
Basically it comes down to the problem of identifying what kernel and
world someone is running. In FreeBSD's case they run parallel releases
of both their 'stable' and 'current' series. The two major series
(stable and current) have their own CVS branches (current is just on the
CVS HEAD). Each release made within the series also has its own branch.
To make things more confusing, the -RELEASE designation only applies to
the actual release while the -STABLE designation applies to continued
development on the stable branch.
DragonFly just has one series. i.e. no parallel development is occuring.
When we release (starting with this upcoming release) we create a branch
for the release. Only bug fixes are allowed to be committed to a
release branch... no new features.
As of this upcoming release, our tags are going to be named based on
the scheme Chris Pressey came up with (the one that got a lot of positive
responses on the lists). We will have three tag names:
DEVELOPMENT
This represents the absolute bleeding edge head of the CVS tree.
When Max commits yet another rearrangement of the Make variable
handling module, or Joerg rearranges the sound drivers, this
is where it goes :-)
PREVIEW
This is a slip tag (not a branch) that we synchronize with the head
of the tree from time to time (just like I did a few days ago). It
represents near-bleeding-edge but likely-to-not-blow-up-in-your-face
work.
RELEASE+subversions
This will be a branch tag. e.g. representing an official release.
So, for example, the upcoming release will be called
DragonFly 1.2.0-RELEASE (the tag name itself will be something more
compressed).
Commits made to a release branch will automatically bump a
subversion, e.g. 1.2.0, 1.2.1, ... 1.2.75. Again, only bug fixes
would be committed to a release branch. So someone running a
release who reports a bug might tell us that is is running 1.2.25,
which gives us a darn good idea exactly what the state of his
system is.
Dave Sharnoff came up with a great idea to prevent commits on the
release branch from getting out-of-synch with the subversions
(which is only incremented once a day at most, if something had
been committed), and that is to have a slip tag within the release
branch that is kept synchronized with the automated subversion
change. This will be what people tracking a RELEASE branch will
be using to keep up to date, rather then tracking the branch tag
itself. That gets into the nitty-gritty and will be mostly
invisible to end-users, but I thought I'd mention it anyway.
We do not regard releases as being production-ready. At some point in
the future we will put together a testing regimen and require a certain
amount of in-the-field-time for a release branch before we start
calling it PRODUCTION. So, e.g. lets say that by the time we get to
1.2.75 there's enough feedback and testing to be able to call it
production, the nomenclature in the boot message would change
from RELEASE to PRODUCTION. Some release branches might never make it
to that exhaulted status.
Unlike FreeBSD subversions of old, our subversions automatically track
commits made to a release branch, so it is expected that the subversion
might grow to a fairly large number.
-Matt
Matthew Dillon
<dillon@backplane.com>
討論串 (同標題文章)
完整討論串 (本文為第 2 之 49 篇)：