(moved to xemacs-beta)
On 6 Mar 2002, Stephen J. Turnbull wrote:
+<strong>cvs -z3 -d :pserver:cvs@cvs.xemacs.org:/pack/xemacscvs
checkout -d xemacs-21.4 -r candidate-21-4 xemacs</strong>
Although I see no reason to keep it private, candidate-21-4 is my
personal workspace, just like ben-mule-21-5 is Ben's and the newGC
stuff is Richard's. But if you feel that there's important stuff
there that should be released, advertising that branch is the wrong
solution. Tell me to hurry up with the release, instead.
Shouldn't people test a release before it is released? Making to-be
stable releases available on a branch (and documenting that) seems like
common practice. Only mentioning the tag on xemacs-beta limits the
audience to stable release testers quite alot.
I reserve the right to fuck things up royally in candidate-21-4. I
have committed code that hasn't been built yet and then gone to bed,
not to return to work on 21.4 for days. It's simply an accounting
convenience for me. CVS is quite good at keeping track of commits,
it's the easiest way to record which patches I've applied, and to be
sure that I'm testing what I've applied.
You can use it at your own risk, you get what you pay for and often
less, it's not XEmacs policy, don't blame anyone but yourself if your
CPU melts down, your dog runs off to Las Vegas with your wife, and
your daughter marries a loan shark after using that code.
If and when I'm willing to be disciplined enough to make sure that the
code I'm committing can be advertised, I'll abolish that branch, and
do something like make a r21-4-release tag.
I don't think people will be upset if code on candidate-21-4 is unstable.
Moving branches for to-be stable releases is often completely broken in
lots of projects. If you get anything from CVS that isn't marked as a
release, you shouldn't expect it to work.
Just my $.02, of course.