Continued development during release process

Continued development during release process

[Bill Wohler]

I have some developers who have been sitting on some changes until MH-E
8.0 is released. Since this is looming (I'm putting out the first
release candidate today), it's time for me to find out how the Emacs
maintainers would like us to proceed.

First of all, if you're handling the release, including tagging and
stuff, please let me know who you are.

Second, once you add a pretest tag, will you make subsequent tags based
upon that tag, or will you simply tag the trunk? The implications for
the MH-E project is that in the former case, my developers can simply
check in their changes. In the latter case, we'll have to branch and
merge until 22.1 is released, which is a lot of extra work (so of
course I'm hoping for the former).

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.

Re: Continued development during release process

[Eli Zaretskii]

> Date: Fri, 21 Apr 2006 14:37:13 -0700
> From: Bill Wohler <wohler@newt.com>
> Cc: mh-e-devel@lists.sourceforge.net
> 
> First of all, if you're handling the release, including tagging and
> stuff, please let me know who you are.

That's not me, and AFAIK no one has stepped forward to volunteer for
the job yet.

> Second, once you add a pretest tag, will you make subsequent tags based
> upon that tag, or will you simply tag the trunk?

I don't really understand the question, so maybe what's below won't
answer it; sorry.

When the pretest is under way, at some point a release-candidate
branch is created.  (I say ``at some point'' because I don't think
there's an agreement whether this should happen right away when the
pretest starts, or later, much closer to the release itself, i.e. at
pretest end.)  This branch is used for the initial release, in this
case for version 22.1, and for all subsequent bug-fix releases that
(at least ideally) fix bugs without introducing major features; these
would be versions 22.2, 22.3, etc., until it is decided by The Powers
That Be that it's time to make another release from the trunk.

If the release branch is _not_ cut as soon as the pretest starts, the
trunk is frozen for anything but bugfixes from the pretest start and
until we branch.  As soon as the branch _is_ cut, it is possible to
resume development commits to the trunk, in parallel with fixing bugs
on the release branch.  (One of the arguments _against_ branching
early is that, given the relatively small number of core developers,
opening the trunk for development might leave too few people to
actively work on fixing bugs on the branch.)

Having said that, a caveat: the above is based on my limited
experience with one of the 21.x releases.  That was a long time ago,
so it's possible that for the upcoming release the procedures will be
different.  AFAIK, this was never seriously discussed, because doing
so far from the pretest is a largely academic dispute.  In any case,
whoever volunteers for the job will have an important say on how the
release process is managed.

HTH

Re: Continued development during release process

[Bill Wohler]

Eli Zaretskii <eliz@gnu.org> writes:

> When the pretest is under way, at some point a release-candidate
> branch is created.  (I say ``at some point'' because I don't think
> there's an agreement whether this should happen right away when the
> pretest starts, or later, much closer to the release itself, i.e. at
> pretest end.)  This branch is used for the initial release, in this
> case for version 22.1, and for all subsequent bug-fix releases that
> (at least ideally) fix bugs without introducing major features; these
> would be versions 22.2, 22.3, etc., until it is decided by The Powers
> That Be that it's time to make another release from the trunk.

Thanks. We'll hold off until that branch is created.

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.



-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: Continued development during release process

[Kim F. Storm]

Bill Wohler <wohler@newt.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> When the pretest is under way, at some point a release-candidate
>> branch is created.  (I say ``at some point'' because I don't think
>> there's an agreement whether this should happen right away when the
>> pretest starts, or later, much closer to the release itself, i.e. at
>> pretest end.)  This branch is used for the initial release, in this
>> case for version 22.1, and for all subsequent bug-fix releases that
>> (at least ideally) fix bugs without introducing major features; these
>> would be versions 22.2, 22.3, etc., until it is decided by The Powers
>> That Be that it's time to make another release from the trunk.
>
> Thanks. We'll hold off until that branch is created.

You can just create your own branch and continue post-22.x work on that
until we branch for the 22.x release.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Continued development during release process

[Bill Wohler]

Kim F. Storm <storm@cua.dk> wrote:

> Bill Wohler <wohler@newt.com> writes:
> 
> > Eli Zaretskii <eliz@gnu.org> writes:
> >
> >> When the pretest is under way, at some point a release-candidate
> >> branch is created.  (I say ``at some point'' because I don't think
> >> there's an agreement whether this should happen right away when the
> >> pretest starts, or later, much closer to the release itself, i.e. at
> >> pretest end.)  This branch is used for the initial release, in this
> >> case for version 22.1, and for all subsequent bug-fix releases that
> >> (at least ideally) fix bugs without introducing major features; these
> >> would be versions 22.2, 22.3, etc., until it is decided by The Powers
> >> That Be that it's time to make another release from the trunk.
> >
> > Thanks. We'll hold off until that branch is created.
> 
> You can just create your own branch and continue post-22.x work on that
> until we branch for the 22.x release.

I am aware of that. I was hoping to avoid it.

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.

Re: Continued development during release process

[Richard Stallman]

    Second, once you add a pretest tag, will you make subsequent tags based
    upon that tag, or will you simply tag the trunk?

I did not understand your question at first because of some CVS jargon
I did not know, but now I understand the issue.

We don't have any rule about this.  I decide what to do,
though I don't implement it in CVS.

I want to keep people's attention focused on the release until the
release actually comes out.  So I will not relegate the coming release
22 to a branch when pretesting starts.

If we reach a late stage of pretesting where there are few bugs, and
mostly waiting for a few specific people to fix them, maybe I will
move 22 to a branch then.


-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: Continued development during release process

[Stefan Monnier]

> I want to keep people's attention focused on the release until the
> release actually comes out.  So I will not relegate the coming release
> 22 to a branch when pretesting starts.

> If we reach a late stage of pretesting where there are few bugs, and
> mostly waiting for a few specific people to fix them, maybe I will
> move 22 to a branch then.

I just take this opportunity to make sure that you won't forget to make
a branch for Emacs-22 at some point.  It can be at the moment when we cut
the release, but no later.  The branch will be used for 22.2, 22.3, ...

You probably knew that, but even very bright people have been known to
forget it,


        Stefan