A *smaller* release concept
Was there any consideration of doing a release that consisted of 1.34.1 and new libraries that have been accepted recently. No other changes. Stable and working libraries such as Boost.Test and Boost.Thread would just be the same as in the 1.34.1 release; however, the package would also contain libraries such as asio that have been waiting on the side lines. -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
Sebastian Redl <sebastian.redl <at> getdesigned.at> writes:
Michael Caisse wrote:
Was there any consideration of doing a release that consisted of 1.34.1 and new libraries that have been accepted recently.
No other changes.
Aren't there new libraries that depend on changes since 1.34.1?
I expect it to be much worse than that: trunk evolved for about a year and a half since the 1.34 branch was created. I don't think it's realistic to move new libraries onto 1.34.1 and expect them to work straight away. What I believe it's going to happen, judging from recent postings by some of the moderators, is that the new release branch is based on 1.34.1 and libraries are going to be moved over one by one in a controlled way, with insufficiently stable ones reverted to their 1.34.1 version (or just removed if they weren't in the previous release). This makes more sense to me. Cheers, Nicola Musatti
Nicola Musatti wrote:
I expect it to be much worse than that: trunk evolved for about a year and a half since the 1.34 branch was created. I don't think it's realistic to move new libraries onto 1.34.1 and expect them to work straight away.
What I believe it's going to happen, judging from recent postings by some of the moderators, is that the new release branch is based on 1.34.1 and libraries are going to be moved over one by one in a controlled way, with insufficiently stable ones reverted to their 1.34.1 version (or just removed if they weren't in the previous release). This makes more sense to me.
Correct, and anything not ready won't be merged to the new release at all: basically the default assumption is "Ship 1.34", and folks have to demonstrate that their new code in Trunk is ready to be merged to release. But ultimately as release manager Beman has the final say on everything! Regards, John.
John Maddock wrote:
Nicola Musatti wrote:
I expect it to be much worse than that: trunk evolved for about a year and a half since the 1.34 branch was created. I don't think it's realistic to move new libraries onto 1.34.1 and expect them to work straight away.
What I believe it's going to happen, judging from recent postings by some of the moderators, is that the new release branch is based on 1.34.1 and libraries are going to be moved over one by one in a controlled way, with insufficiently stable ones reverted to their 1.34.1 version (or just removed if they weren't in the previous release). This makes more sense to me.
Correct, and anything not ready won't be merged to the new release at all: basically the default assumption is "Ship 1.34", and folks have to demonstrate that their new code in Trunk is ready to be merged to release. But ultimately as release manager Beman has the final say on everything!
Yep. This is setting us up for a fork. The trunk will drift further and further away from the release branch; if it's too hard now to reconcile trunk and 1.34, it will be even harder to do that for trunk and 1.35, and nearly impossible for trunk (if it still exists at all) and 1.36. At some point one of the two branches will be cut off and someone will suffer, no matter which branch prevails.
on Wed Oct 17 2007, "Peter Dimov" <pdimov-AT-pdimov.com> wrote:
John Maddock wrote:
Nicola Musatti wrote:
I expect it to be much worse than that: trunk evolved for about a year and a half since the 1.34 branch was created. I don't think it's realistic to move new libraries onto 1.34.1 and expect them to work straight away.
What I believe it's going to happen, judging from recent postings by some of the moderators, is that the new release branch is based on 1.34.1 and libraries are going to be moved over one by one in a controlled way, with insufficiently stable ones reverted to their 1.34.1 version (or just removed if they weren't in the previous release). This makes more sense to me.
Correct, and anything not ready won't be merged to the new release at all: basically the default assumption is "Ship 1.34", and folks have to demonstrate that their new code in Trunk is ready to be merged to release. But ultimately as release manager Beman has the final say on everything!
Yep.
This is setting us up for a fork. The trunk will drift further and further away from the release branch; if it's too hard now to reconcile trunk and 1.34, it will be even harder to do that for trunk and 1.35, and nearly impossible for trunk (if it still exists at all) and 1.36. At some point one of the two branches will be cut off and someone will suffer, no matter which branch prevails.
Interesting you should say that; Among the moderators who discussed the 1.35 release process, all but one of us was very concerned about that issue. Another problem with the drift is that the trunk very quickly becomes an invalid proving ground for a library's ability to work in context of the release branch. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams <dave <at> boost-consulting.com> writes:
on Wed Oct 17 2007, "Peter Dimov" <pdimov-AT-pdimov.com> wrote: [...]
This is setting us up for a fork. The trunk will drift further and further away from the release branch; if it's too hard now to reconcile trunk and 1.34, it will be even harder to do that for trunk and 1.35, and nearly impossible for trunk (if it still exists at all) and 1.36. At some point one of the two branches will be cut off and someone will suffer, no matter which branch prevails.
Interesting you should say that; Among the moderators who discussed the 1.35 release process, all but one of us was very concerned about that issue. Another problem with the drift is that the trunk very quickly becomes an invalid proving ground for a library's ability to work in context of the release branch.
I cannot think of a softer way out of this problem than the unconditional merge of the release branch on trunk immediately after the release is issued. Libraries that were merged to the release branch specifically for the current release should not differ; for the others developers should be forewarned, so that they may move their stuff to private development branches before the merge takes place. Cheers, Nicola Musatti
David Abrahams wrote:
on Wed Oct 17 2007, "Peter Dimov" <pdimov-AT-pdimov.com> wrote:
John Maddock wrote:
Nicola Musatti wrote:
I expect it to be much worse than that: trunk evolved for about a year and a half since the 1.34 branch was created. I don't think it's realistic to move new libraries onto 1.34.1 and expect them to work straight away.
What I believe it's going to happen, judging from recent postings by some of the moderators, is that the new release branch is based on 1.34.1 and libraries are going to be moved over one by one in a controlled way, with insufficiently stable ones reverted to their 1.34.1 version (or just removed if they weren't in the previous release). This makes more sense to me. Correct, and anything not ready won't be merged to the new release at all: basically the default assumption is "Ship 1.34", and folks have to demonstrate that their new code in Trunk is ready to be merged to release. But ultimately as release manager Beman has the final say on everything! Yep.
This is setting us up for a fork. The trunk will drift further and further away from the release branch; if it's too hard now to reconcile trunk and 1.34, it will be even harder to do that for trunk and 1.35, and nearly impossible for trunk (if it still exists at all) and 1.36. At some point one of the two branches will be cut off and someone will suffer, no matter which branch prevails.
Interesting you should say that; Among the moderators who discussed the 1.35 release process, all but one of us was very concerned about that issue. Another problem with the drift is that the trunk very quickly becomes an invalid proving ground for a library's ability to work in context of the release branch.
We will soon find out how serious the problem of drift is, since over the next week we will be starting to merge libraries from trunk to release. Until we've tried that, and see what works and what doesn't, it is just speculation. --Beman
Nicola Musatti wrote:
Sebastian Redl <sebastian.redl <at> getdesigned.at> writes:
I expect it to be much worse than that: trunk evolved for about a year and a half since the 1.34 branch was created. I don't think it's realistic to move new libraries onto 1.34.1 and expect them to work straight away.
Actually it works pretty well. I did a test about 5 months ago of putting all the new libraries on 1.34 and it worked fine. I'm an advocate of 1.35 being released with just new libraries, but I'm willing to give the controlled/limited update approach a chance. As part of the release team, I'll be watching for regressions so we can revert quickly to a stable base. Jeff
Jeff Garland wrote:
Nicola Musatti wrote:
Sebastian Redl <sebastian.redl <at> getdesigned.at> writes:
I expect it to be much worse than that: trunk evolved for about a year and a half since the 1.34 branch was created. I don't think it's realistic to move new libraries onto 1.34.1 and expect them to work straight away.
Actually it works pretty well. I did a test about 5 months ago of putting all the new libraries on 1.34 and it worked fine. I'm an advocate of 1.35 being released with just new libraries, but I'm willing to give the controlled/limited update approach a chance. As part of the release team, I'll be watching for regressions so we can revert quickly to a stable base.
FWIW I've been using a mix of the HEAD and RC_1_34_0 branches from CVS for about a year and have been constantly cherry picking updates from svn trunk since it went live with no non-trivial problems that I can remember. - Michael Marcin
Michael Caisse wrote:
Was there any consideration of doing a release that consisted of 1.34.1 and new libraries that have been accepted recently.
No other changes.
Stable and working libraries such as Boost.Test and Boost.Thread would just be the same as in the 1.34.1 release; however, the package would also contain libraries such as asio that have been waiting on the side lines.
Yes, this was one of many proposals for the next release that were actively considered, in the end, it came down to "stop discussing and get on with it" ;-) John.
on Tue Oct 16 2007, Michael Caisse <boost-AT-objectmodelingdesigns.com> wrote:
Was there any consideration of doing a release that consisted of 1.34.1 and new libraries that have been accepted recently.
No other changes.
Yes, it was considered. Several of us supported the idea, and several others (who have major changes waiting to be released for over a year) were strongly opposed. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
participants (9)
-
Beman Dawes -
David Abrahams -
Jeff Garland -
John Maddock -
Michael Caisse -
Michael Marcin -
Nicola Musatti -
Peter Dimov -
Sebastian Redl