Re:[boost] Re: [1.32 Plan] Stalled forever?
The branch should occur now. MPL update can go into the next release. Or you can see it a slightly different way. Branch and release 1.32 now. Rebranch and release 1.32 when MPL update has been added and any related issues resolved.
Please be patient.
Aleksey is having a hard time getting finished and the release date has slipped; it's true. That said, the very existence of this release is due to our need to have a Boost release with an updated MPL for http://www.boost-consulting.com/mplbook. The CD for the book has to be final by early next month, and there's no possible way we can do two releases before that time. The schedule is getting increasingly tight; I just hope we can do _one_.
I considered what would happen if we branched now and Aleksey integrated his changes into the release branch. It seems apparent that it would only slow the release down further, since the changes would have to be integrated into the trunk, too.
This would be even worse than the current situation. My real question was what is the downside of including MPL in release 1.33 rather than 1.32 ? The important thing is the release date - not the release number. I believe that the rest of concentrating on a bug free release of 1.32 while others get MPL ready for the NEXT release will result in a sooner release date for the current library + MPL than otherwise. So my suggestion is: Branch 1.32 rc now - make only bug fixes. Actually at this point they aren't really bugs so much as accommodation to different platforms, tool configuration scripts. Etc. Define 1.33 as 1.32 + new MPL and release it as soon as its ready - I would envision this coming out a short time (4-8 weeks? - whatever) after 1.32. If MPL slips in with no ripple effect - well no harm done. If MPL ripples through creating a bunch of new test failure, still no harm done, 1.32 is still available. This would in effect de-couple the release progress of the boost library as a whole from any issues associated with a particular library. I didn't not think that I would be able to make the release for the serialization library - indeed - I couldn't make the original one. I was prepared to work at my own pace and upload a "serialization add-in" compatible with the latest release. It would be then up to the manager of the next to decide whether it was worthy to be included in the next "boost release" Actually, all boost libraries - including an MPL update, should take this approach. Robert Ramey
Robert Ramey wrote:
Define 1.33 as 1.32 + new MPL and release it as soon as its ready - I would envision this coming out a short time (4-8 weeks? - whatever) after 1.32. If
I kindly disagree with this. It would be kind of confusing for users to have release 1.32 and very soon after it (few weeks) release 1.33 B.
On 2004-08-26, Bronek Kozicki <brok@rubikon.pl> wrote:
Robert Ramey wrote:
Define 1.33 as 1.32 + new MPL and release it as soon as its ready - I would envision this coming out a short time (4-8 weeks? - whatever) after 1.32. If I kindly disagree with this. It would be kind of confusing for users to have release 1.32 and very soon after it (few weeks) release 1.33
Why confusing? Inconvenient, maybe, but not confusing. That could be dealt with by putting something in the release notes/announcement saying that that is going to happen - those people who use the MPL may well wait for 1.33; others won't because of all the other good stuff. Of course, this ignores the bigger issue of the amount of effort taken to put a release together. On the positive side, it might take a bit of pressure of Aleksy in getting the new MPL in place... but it also nearly doubles the release effort. This is really rather othogonal to the issue of whether 1.32 should branch now, though. phil -- change name before "@" to "phil" for email
"Robert Ramey" <ramey@rrsd.com> writes:
The branch should occur now. MPL update can go into the next release. Or you can see it a slightly different way. Branch and release 1.32 now. Rebranch and release 1.32 when MPL update has been added and any related issues resolved.
Please be patient.
Aleksey is having a hard time getting finished and the release date has slipped; it's true. That said, the very existence of this release is due to our need to have a Boost release with an updated MPL for http://www.boost-consulting.com/mplbook. The CD for the book has to be final by early next month, and there's no possible way we can do two releases before that time. The schedule is getting increasingly tight; I just hope we can do _one_.
I considered what would happen if we branched now and Aleksey integrated his changes into the release branch. It seems apparent that it would only slow the release down further, since the changes would have to be integrated into the trunk, too.
This would be even worse than the current situation.
My real question was what is the downside of including MPL in release 1.33 rather than 1.32 ? The important thing is the release date - not the release number. I believe that the rest of concentrating on a bug free release of 1.32 while others get MPL ready for the NEXT release will result in a sooner release date for the current library + MPL than otherwise.
On what basis have you arrived at that conclusion? Have you been following the progress of the new MPL work? I hate to repeat myself, but: The CD for the book (which must contain a Boost release with the new MPL stuff) has to be final by early next month, and my assessment is that there's no possible way we can do two releases before then. Therefore, the best bet is to do one release. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
My real question was what is the downside of including MPL in release 1.33 rather than 1.32 ? The important thing is the release date - not the release number. I believe that the rest of concentrating on a bug free release of 1.32 while others get MPL ready for the NEXT release will result in a sooner release date for the current library + MPL than otherwise. So my suggestion is:
Branch 1.32 rc now - make only bug fixes. Actually at this point they aren't really bugs so much as accommodation to different platforms, tool configuration scripts. Etc.
Normally that would work, but since the next MPL *has* to be released inside the next month (for the book deadline), there is no way we can get two releases out in that time IMO. I think we're just going to have to patient for a week or two.
I didn't not think that I would be able to make the release for the serialization library - indeed - I couldn't make the original one. I was prepared to work at my own pace and upload a "serialization add-in" compatible with the latest release. It would be then up to the manager of the next to decide whether it was worthy to be included in the next "boost release"
Actually, all boost libraries - including an MPL update, should take this approach.
Ideally yes, I think the next release should be schedule-based rather than feature based; this release and the lat one were essentially delayed because they were feature based and sometimes things just take longer than you expect :-( John.
participants (5)
-
Bronek Kozicki -
David Abrahams -
John Maddock -
Phil Richards -
Robert Ramey