[1.33.0] Release schedule suggestion
Here's my suggestion for a release schedule. We allow two weeks to get all of the new features and bug-fixes we want into CVS, but still try to keep things sane. Then we fix bugs on the CVS trunk for a week, branch and fix bugs for another week, and then release on May 1. So, the important dates are: April 15 (two weeks from today): feature-freeze on CVS trunk. April 22 (three weeks from today): branch for 1.33.0 May 1 (just over four weeks from today): release 1.33.0 It's aggressive, but we should get this out the door well before summer (when, traditionally, Boost development slows a bit), and we can do it if we focus. If we do well keeping to a tight schedule, perhaps we'll get better about releasing more often and the whole process will become less painful. Doug
At Friday 2005-04-01 15:17, you wrote:
Here's my suggestion for a release schedule. We allow two weeks to get all of the new features and bug-fixes we want into CVS, but still try to keep things sane. Then we fix bugs on the CVS trunk for a week, branch and fix bugs for another week, and then release on May 1. So, the important dates are:
April 15 (two weeks from today): feature-freeze on CVS trunk. April 22 (three weeks from today): branch for 1.33.0
I'll say this again.... if you branch, branch the development that's NOT related to 1.33.0 there should be NO reason for the testers to have to check out some new tag just because we're about to do a release.
May 1 (just over four weeks from today): release 1.33.0
It's aggressive, but we should get this out the door well before summer (when, traditionally, Boost development slows a bit), and we can do it if we focus. If we do well keeping to a tight schedule, perhaps we'll get better about releasing more often and the whole process will become less painful.
Doug
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
Victor A. Wagner Jr. wrote:
At Friday 2005-04-01 15:17, you wrote:
Here's my suggestion for a release schedule. We allow two weeks to get all of the new features and bug-fixes we want into CVS, but still try to keep things sane. Then we fix bugs on the CVS trunk for a week, branch and fix bugs for another week, and then release on May 1. So, the important dates are: April 15 (two weeks from today): feature-freeze on CVS trunk. April 22 (three weeks from today): branch for 1.33.0
I'll say this again.... if you branch, branch the development that's NOT related to 1.33.0
I'll agree again. The changes I check in when we are in release mode (have a release branch active) _always_ go to both the trunk and the branch. The branch doesn't help me in any way. Apr 15: feature freeze Release "when it's done" I say.
On Apr 2, 2005, at 3:53 AM, Peter Dimov wrote:
Victor A. Wagner Jr. wrote:
At Friday 2005-04-01 15:17, you wrote:
Here's my suggestion for a release schedule. We allow two weeks to get all of the new features and bug-fixes we want into CVS, but still try to keep things sane. Then we fix bugs on the CVS trunk for a week, branch and fix bugs for another week, and then release on May 1. So, the important dates are: April 15 (two weeks from today): feature-freeze on CVS trunk. April 22 (three weeks from today): branch for 1.33.0
I'll say this again.... if you branch, branch the development that's NOT related to 1.33.0
I'll agree again. The changes I check in when we are in release mode (have a release branch active) _always_ go to both the trunk and the branch. The branch doesn't help me in any way.
Fair enough.
Apr 15: feature freeze Release "when it's done"
"When it's done" is a rather unmotivating release date. We need to set a date and try to hit it, based on the principle that nothing happens before the 11th hour. April 15th feature freeze, try for May 1st release. Doug
Douglas Gregor wrote:
On Apr 2, 2005, at 3:53 AM, Peter Dimov wrote:
Apr 15: feature freeze Release "when it's done"
"When it's done" is a rather unmotivating release date. We need to set a date and try to hit it, based on the principle that nothing happens before the 11th hour. April 15th feature freeze, try for May 1st release.
I didn't define "done", so there's probably a misunderstanding. Let me rephrase: 1. Apr 15 feature freeze 2. Release candidate when there are no test failures (worth discussing) 3. Release when there are no known bugs (no need to wait till May 1st)
Douglas Gregor <doug.gregor@gmail.com> writes:
On Apr 2, 2005, at 3:53 AM, Peter Dimov wrote:
Victor A. Wagner Jr. wrote:
At Friday 2005-04-01 15:17, you wrote:
Here's my suggestion for a release schedule. We allow two weeks to get all of the new features and bug-fixes we want into CVS, but still try to keep things sane. Then we fix bugs on the CVS trunk for a week, branch and fix bugs for another week, and then release on May 1. So, the important dates are: April 15 (two weeks from today): feature-freeze on CVS trunk. April 22 (three weeks from today): branch for 1.33.0
I'll say this again.... if you branch, branch the development that's NOT related to 1.33.0
I'll agree again. The changes I check in when we are in release mode (have a release branch active) _always_ go to both the trunk and the branch. The branch doesn't help me in any way.
Fair enough.
Hey, this is a pretty radical idea. None of the projects I've seen work that way, and it won't be possible to use this approach if we have to make a 1.33.1. I'm not going to say flat out that it's the wrong approach, but at least there ought to be a loud announcement that we're thinking of turning the release procedure on its head. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Apr 2, 2005, at 11:32 AM, David Abrahams wrote:
Douglas Gregor <doug.gregor@gmail.com> writes:
On Apr 2, 2005, at 3:53 AM, Peter Dimov wrote:
Victor A. Wagner Jr. wrote:
I'll say this again.... if you branch, branch the development that's NOT related to 1.33.0
I'll agree again. The changes I check in when we are in release mode (have a release branch active) _always_ go to both the trunk and the branch. The branch doesn't help me in any way.
Fair enough.
Hey, this is a pretty radical idea. None of the projects I've seen work that way, and it won't be possible to use this approach if we have to make a 1.33.1. I'm not going to say flat out that it's the wrong approach, but at least there ought to be a loud announcement that we're thinking of turning the release procedure on its head.
From a technical standpoint, there *must* be a branch in CVS to mark the 1.33.0 release. It needs to be there so that 1.33.1 can be based on something, as you said. I can't imagine any disagreement with the assertion that we need to have our releases stored as branches in CVS. The difference between the two approaches is when that branch is created. In the traditional branch-then-stabilize-for-release model, the branch coincides with feature freeze: new features go into the trunk, only bug fixes go into the branch. In the model Victor and Peter are advocating, the branch coincides with the the release: the release manager branches the release and builds the release tarballs in the same step. Those are the extremes. For any given project there is a particular point between those two extremes (inclusive!) that works best. GCC is at the branch-then-stabilize-for-release end of the spectrum, because they have a large number of contributors, maintainers, and subprojects that are continually evolving, so they need to separate out the "stabilizing" from the "further development". Lots of small projects are at the other end of the spectrum: the Parallel BGL, for instance, was released and then branched. There aren't any subprojects, there are few developers, and all developers are in the same building. There are many factors that push the branch date earlier or later. As Peter says, making the branch earlier makes fixing bugs more tedious because one has to check things in on both branches. On the other hand, making the branch later means that developers have to either wait longer before adding new features or put those features on a branch. Perhaps there is just a simple relationship here: branching earlier encourages new features and further development, whereas branching later encourages stabilizing existing code. There's one solution that everyone can agree on: if we can keep mainline CVS working well on all of our platforms and generally stay near the "zero regressions" mark, life will be better. The differences between the two extremes shrink because the time between freeze and release shrinks, so the penalties associated with branching "too early" vs. "too late" are decreased. So, I don't want to pick a branch date now. Let's see how things go after we freeze on April 15th and shoot for that May 1 release date. Doug
Douglas Gregor <doug.gregor@gmail.com> writes:
On Apr 2, 2005, at 11:32 AM, David Abrahams wrote:
Douglas Gregor <doug.gregor@gmail.com> writes:
On Apr 2, 2005, at 3:53 AM, Peter Dimov wrote:
Victor A. Wagner Jr. wrote:
I'll say this again.... if you branch, branch the development that's NOT related to 1.33.0
I'll agree again. The changes I check in when we are in release mode (have a release branch active) _always_ go to both the trunk and the branch. The branch doesn't help me in any way.
Fair enough.
Hey, this is a pretty radical idea. None of the projects I've seen work that way, and it won't be possible to use this approach if we have to make a 1.33.1. I'm not going to say flat out that it's the wrong approach, but at least there ought to be a loud announcement that we're thinking of turning the release procedure on its head.
From a technical standpoint, there *must* be a branch in CVS to mark the 1.33.0 release. It needs to be there so that 1.33.1 can be based on something, as you said.
Technically, no. You could use a tag, and then branch from there. I don't neccessarily recommend it though.
I can't imagine any disagreement with the assertion that we need to have our releases stored as branches in CVS.
The difference between the two approaches is when that branch is created. In the traditional branch-then-stabilize-for-release model, the branch coincides with feature freeze: new features go into the trunk, only bug fixes go into the branch. In the model Victor and Peter are advocating, the branch coincides with the the release: the release manager branches the release and builds the release tarballs in the same step.
Whatever, it's still a pretty radical idea. That isn't the way we've been doing things, and it means people will have to be a *lot* more careful with checkins to the trunk during the release period. Everyone deserves at the very least a loud heads-up. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"Peter Dimov" <pdimov@mmltd.net> escribió en el mensaje news:004d01c53761$6413ecf0$6501a8c0@pdimov2...
Victor A. Wagner Jr. wrote:
At Friday 2005-04-01 15:17, you wrote:
Here's my suggestion for a release schedule. We allow two weeks to get all of the new features and bug-fixes we want into CVS, but still try to keep things sane. Then we fix bugs on the CVS trunk for a week, branch and fix bugs for another week, and then release on May 1. So, the important dates are: April 15 (two weeks from today): feature-freeze on CVS trunk. April 22 (three weeks from today): branch for 1.33.0
I'll say this again.... if you branch, branch the development that's NOT related to 1.33.0
I'll agree again. The changes I check in when we are in release mode (have a release branch active) _always_ go to both the trunk and the branch. The branch doesn't help me in any way.
Apr 15: feature freeze Release "when it's done"
FWIW, I agree. In fact, it took some time to understand our current model becasue I had my mind setup with release-THEN-branch. I just couldn't get into the idea of working on something else than a release (once the release is sheduled). Even in my own projects, I never move past a release without finishing it first; so I couldn't understood why was there an early branch. As Peter, I just have to _always_ propagate my work into the Release branch simply becasue I wouldn't be working on anything but the release until it's finish. In the odd event that I have something terribly hot that I can't wait to commit for a post-release version, I would just keep it in my disk. Just my 2c Fernando Cacciola SciSoft
On Apr 4, 2005, at 4:13 PM, Fernando Cacciola wrote:
"Peter Dimov" <pdimov@mmltd.net> escribió en el mensaje news:004d01c53761$6413ecf0$6501a8c0@pdimov2...
I'll agree again. The changes I check in when we are in release mode (have a release branch active) _always_ go to both the trunk and the branch. The branch doesn't help me in any way.
Apr 15: feature freeze Release "when it's done"
FWIW, I agree. In fact, it took some time to understand our current model becasue I had my mind setup with release-THEN-branch. I just couldn't get into the idea of working on something else than a release (once the release is sheduled). Even in my own projects, I never move past a release without finishing it first; so I couldn't understood why was there an early branch. As Peter, I just have to _always_ propagate my work into the Release branch simply becasue I wouldn't be working on anything but the release until it's finish.
Doesn't that assume that the work required for release is something that you're interested in? I'll provide a contrarian example. In the run-up to Boost 1.32.0, I'd finished all that I wanted to do with the Graph library and had stabilized it well before other libraries were ready (e.g., MPL, 'cause they had just finished their book). But, I had lots more that needed to go into the Graph library so that our work could continue. For me, the release branch happened too late, and I ended up creating the graph_devel_1_33_0 branch for everything that would go into 1.33.0 after 1.32.0 had branched. It was also a pain, just like checking into a release branch. Earlier branches and late branches all have benefits and problems. Only shortening the time between freeze and branch solves them. Doug
At Monday 2005-04-04 14:13, you wrote:
"Peter Dimov" <pdimov@mmltd.net> escribió en el mensaje news:004d01c53761$6413ecf0$6501a8c0@pdimov2...
Victor A. Wagner Jr. wrote:
At Friday 2005-04-01 15:17, you wrote:
Here's my suggestion for a release schedule. We allow two weeks to get all of the new features and bug-fixes we want into CVS, but still try to keep things sane. Then we fix bugs on the CVS trunk for a week, branch and fix bugs for another week, and then release on May 1. So, the important dates are: April 15 (two weeks from today): feature-freeze on CVS trunk. April 22 (three weeks from today): branch for 1.33.0
I'll say this again.... if you branch, branch the development that's NOT related to 1.33.0
I'll agree again. The changes I check in when we are in release mode (have a release branch active) _always_ go to both the trunk and the branch. The branch doesn't help me in any way.
Apr 15: feature freeze Release "when it's done"
FWIW, I agree. In fact, it took some time to understand our current model becasue I had my mind setup with release-THEN-branch. I just couldn't get into the idea of working on something else than a release (once the release is sheduled). Even in my own projects, I never move past a release without finishing it first; so I couldn't understood why was there an early branch. As Peter, I just have to _always_ propagate my work into the Release branch simply becasue I wouldn't be working on anything but the release until it's finish. In the odd event that I have something terribly hot that I can't wait to commit for a post-release version, I would just keep it in my disk.
A problem that occurs is that some portion of the libraries may be all set to go for 1.33. The people who work on that want to start on 1.34 and have _nothing_ to do with any of the rest of the library. Given the diverse nature of how the boost libraries interconnect, it's amazing to me that we want to release the entire thing at _any_ point. Be that as it may, there's apparently going to be an official 1.33.0 "release" and folks working on other things (that ARE in 1.33, but will be updated in 1.34) justifiably want to work on THIER stuff. They need to put their work someplace. Therefore creating a branch point is likely required.
Just my 2c
Fernando Cacciola SciSoft
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
On Mon, 04 Apr 2005 18:35:22 -0700, Victor A. Wagner Jr. wrote
A problem that occurs is that some portion of the libraries may be all set to go for 1.33. The people who work on that want to start on 1.34 and have _nothing_ to do with any of the rest of the library. Given the diverse nature of how the boost libraries interconnect, it's amazing to me that we want to release the entire thing at _any_ point. Be that as it may, there's apparently going to be an official 1.33.0 "release" and folks working on other things (that ARE in 1.33, but will be updated in 1.34) justifiably want to work on THIER stuff. They need to put their work someplace. Therefore creating a branch point is likely required.
And I'd guess that the number of people that are done and working on 1.34 will be less than the people working on 1.33. So you can argue that making the 'eager beavers' branch is less work overall than the current process. They also have the option of working on the main branch and not checking in while the release is going (they can always check out a new tree for minor bug fixes if an emergency arises). And I totally agree with Doug that the only true solution to reduce the pain is to shorten the time. All of the options are a pain when the release process takes 2.5 months. Jeff
"Victor A. Wagner Jr." <vawjr@rudbek.com> writes:
A problem that occurs is that some portion of the libraries may be all set to go for 1.33. The people who work on that want to start on 1.34 and have _nothing_ to do with any of the rest of the library. Given the diverse nature of how the boost libraries interconnect, it's amazing to me that we want to release the entire thing at _any_ point. Be that as it may, there's apparently going to be an official 1.33.0 "release" and folks working on other things (that ARE in 1.33, but will be updated in 1.34) justifiably want to work on THIER stuff. They need to put their work someplace. Therefore creating a branch point is likely required.
There's no need for an "official" branch point. Anyone who wants to do that can make his own branch at any point. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"Peter Dimov" <pdimov@mmltd.net> escribió en el mensaje news:004d01c53761$6413ecf0$6501a8c0@pdimov2...
Victor A. Wagner Jr. wrote:
At Friday 2005-04-01 15:17, you wrote:
Here's my suggestion for a release schedule. We allow two weeks to get all of the new features and bug-fixes we want into CVS, but still try to keep things sane. Then we fix bugs on the CVS trunk for a week, branch and fix bugs for another week, and then release on May 1. So, the important dates are: April 15 (two weeks from today): feature-freeze on CVS trunk. April 22 (three weeks from today): branch for 1.33.0
I'll say this again.... if you branch, branch the development that's NOT related to 1.33.0
I'll agree again. The changes I check in when we are in release mode (have a release branch active) _always_ go to both the trunk and the branch. The branch doesn't help me in any way.
Apr 15: feature freeze Release "when it's done"
FWIW, I agree. In fact, it took some time to understand our current model becasue I had my mind setup with release-THEN-branch. I just couldn't get into the idea of working on something else than a release (once the release is sheduled). Even in my own projects, I never move past a release without finishing it first; so I couldn't understood why was there an early branch. As Peter, I just have to _always_ propagate my work into the Release branch simply becasue I wouldn't be working on anything but the release until it's finish. In the odd event that I have something terribly hot that I can't wait to commit for a post-release version, I would just keep it in my disk. Just my 2c Fernando Cacciola SciSoft
participants (7)
-
David Abrahams -
Doug Gregor -
Douglas Gregor -
Fernando Cacciola -
Jeff Garland -
Peter Dimov -
Victor A. Wagner Jr.