[1.48.0] Schedule discussion
In the "[boost] [1.47.0] Release branch now closed" thread, Daniel James and I discussed possible schedules for 1.48: Beman>>> While the release managers haven't talked about the 1.48.0 schedule Beman>>> yet, I personally would like to get back to our traditional quarterly Beman>>> schedule. That would mean 1.48.0 would be scheduled for the first Beman>>> Monday in August. Daniel>> We haven't got enough time for that. If we release 1.47 after a 2 week Daniel>> beta (i.e. pretty quickly), it will be released on 4th July, leaving Daniel>> just under a month before the first Monday in August. Beman> Agreed, but we could aim for as short a 1.48 schedule as is reasonable Beman> so that the 1.49 schedule is then back on the quarterly cycle. A 1.48 beta 5 weeks after 1.47 ships seems doable. That would be about August 8th, and then the release 3 weeks later, or about August 29. The 1.49 release then would be back on schedule for the first Monday in November. To make the above happen, we would need to open branches/release for merges immediately after 1.47 ships. Or maybe create a branch now for 1.48. Thoughts? --Beman
On 19 June 2011 13:23, Beman Dawes <bdawes@acm.org> wrote:
A 1.48 beta 5 weeks after 1.47 ships seems doable. That would be about August 8th, and then the release 3 weeks later, or about August 29.
The 1.49 release then would be back on schedule for the first Monday in November.
If we want to have longer beta periods and point releases, it's worth considering slowing down a little, perhaps 4 month release cycles, giving 3 releases a year.
To make the above happen, we would need to open branches/release for merges immediately after 1.47 ships. Or maybe create a branch now for 1.48.
Thoughts?
I think we'll need to try to get major changes ready before the release cycle starts. I'm mainly thinking about new libraries, IMO we should require that they've been approved by the release managers before this release cycle starts and have quite a short window for them to merge (a 1.48 branch would make the easier). I also have a new version of the unordered containers and some changes to quickbook in the works, but they can wait if they must.
Daniel James wrote:
If we want to have longer beta periods and point releases, it's worth considering slowing down a little, perhaps 4 month release cycles, giving 3 releases a year.
+1 And if point releases could be avoided as much as possible, it would be even better. Regards, Thomas
Beman Dawes wrote:
In the "[boost] [1.47.0] Release branch now closed" thread, Daniel James and I discussed possible schedules for 1.48:
Beman>>> While the release managers haven't talked about the 1.48.0 schedule Beman>>> yet, I personally would like to get back to our traditional quarterly Beman>>> schedule. That would mean 1.48.0 would be scheduled for the first Beman>>> Monday in August.
Daniel>> We haven't got enough time for that. If we release 1.47 after a 2 week Daniel>> beta (i.e. pretty quickly), it will be released on 4th July, leaving Daniel>> just under a month before the first Monday in August.
Beman> Agreed, but we could aim for as short a 1.48 schedule as is reasonable Beman> so that the 1.49 schedule is then back on the quarterly cycle.
A 1.48 beta 5 weeks after 1.47 ships seems doable. That would be about August 8th, and then the release 3 weeks later, or about August 29.
The 1.49 release then would be back on schedule for the first Monday in November.
To make the above happen, we would need to open branches/release for merges immediately after 1.47 ships. Or maybe create a branch now for 1.48.
Thoughts?
How about tweaking your "quarterly release rule" to say. release x +1 is scheduled for 3 months after the release of x. This will account for the fact that not every release occurs on schedule. It will also make it easier for library developers in that I always will know what my deadline is with 3 months notice. Robert Ramey
--Beman _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
A 1.48 beta 5 weeks after 1.47 ships seems doable. That would be about August 8th, and then the release 3 weeks later, or about August 29.
The 1.49 release then would be back on schedule for the first Monday in November.
5 weeks is not enough to start something big, I'd consider 1.48 to be little more than a bugfix version, a 1.47.1 in other words.
To make the above happen, we would need to open branches/release for merges immediately after 1.47 ships. Or maybe create a branch now for 1.48.
Thoughts?
How about tweaking your "quarterly release rule" to say.
release x +1 is scheduled for 3 months after the release of x.
This will account for the fact that not every release occurs on schedule. It will also make it easier for library developers in that I always will know what my deadline is with 3 months notice.
Robert Ramey
+1
On 19 June 2011 20:29, Christophe Henry <christophe.j.henry@googlemail.com> wrote:
A 1.48 beta 5 weeks after 1.47 ships seems doable. That would be about August 8th, and then the release 3 weeks later, or about August 29.
The 1.49 release then would be back on schedule for the first Monday in November.
5 weeks is not enough to start something big, I'd consider 1.48 to be little more than a bugfix version, a 1.47.1 in other words.
Part of the reason for having frequent releases is so that they aren't 'something big'. I think including Boost.Move is enough to justify a release. And it might also include the new version of the unordered containers.
A 1.48 beta 5 weeks after 1.47 ships seems doable. That would be about August 8th, and then the release 3 weeks later, or about August 29.
The 1.49 release then would be back on schedule for the first Monday in November.
5 weeks is not enough to start something big, I'd consider 1.48 to be little more than a bugfix version, a 1.47.1 in other words.
Part of the reason for having frequent releases is so that they aren't 'something big'. I think including Boost.Move is enough to justify a release. And it might also include the new version of the unordered containers.
I understand the theory, but I like the routine of planing in 3 months cycles. Uncomplicated and I know when the release branch is going to be closed when the calendar does not work. A release after 5 weeks is likely to force me to maintain 2 versions. Frankly, I'd have preferred to wait a week more and get Boost.Move into the 1.47. Christophe
On 20 June 2011 21:03, Christophe Henry <christophe.j.henry@googlemail.com> wrote:
I understand the theory, but I like the routine of planing in 3 months cycles. Uncomplicated and I know when the release branch is going to be closed when the calendar does not work. A release after 5 weeks is likely to force me to maintain 2 versions. Frankly, I'd have preferred to wait a week more and get Boost.Move into the 1.47.
The release isn't after 5 weeks, the beta is. Including Boost.Move would add more than a week's delay, our policy is to allow plenty of time between adding a new library to the release branch and the beta. That's why I was saying that we'd need to make sure new libraries are ready to merge when the release branch opens.
Hi all, Beman Dawes wrote:
In the "[boost] [1.47.0] Release branch now closed" thread, Daniel James and I discussed possible schedules for 1.48:
out of pure curiosity: why not a Boost 2.0 release ? I think that 47 releases in the 1.0 series and an additional number of "point" releases is enough to warrant an upgrade of the major version number. An extra long bug- sprint might be in order, so that the hallmark of Boost 2.0 would not be an incredible amount of new features, but incredible stability. And I believe that, with an upgrade of the version number, we would see quite a big effect in the number of users and in the press coverage of Boost. Just my Euro 0.02, Rüdiger
On Sat, Jun 25, 2011 at 09:18:40PM +0200, Ruediger Berlich wrote:
Hi all,
Beman Dawes wrote:
In the "[boost] [1.47.0] Release branch now closed" thread, Daniel James and I discussed possible schedules for 1.48:
out of pure curiosity: why not a Boost 2.0 release ? I think that 47 releases in the 1.0 series and an additional number of "point" releases is enough to warrant an upgrade of the major version number. An extra long bug- sprint might be in order, so that the hallmark of Boost 2.0 would not be an incredible amount of new features, but incredible stability.
Bumping the major version number would turn some people off, as in most version numbering schemes, that tends to mean that some major incompatibilities were introduced or that some restructuring has occured. I've seen and caught code in Boost that will break if the major version number is bumped, as it only checked the minor version in preprocessor tests. It wouldn't be far-fetched to assume that other people have made such assumptions as well. Personally I prefer that code and scripts that have worked in the past continue to work to some degree, particularly if the change is for just "because we can" or for cosmetic reasons. This (personally) sounds to me of being inspired by the recent version number bump of the Linux kernel to 3.0.
And I believe that, with an upgrade of the version number, we would see quite a big effect in the number of users and in the press coverage of Boost.
As per the above comment, major version bumps also scare people. I would say that the effect of a major bump would be rather anticlimatic when/if people get to the changelog and see that nothing interesting has occured. If I saw a bump of Boost to 2.x.0, I would expect that something massive and somewhat breaking has occurred, along the lines of: * complete build system revamp, with different build methods and library naming convention; * modularisation of boost libraries into largely standalone components, with some infrastructure to roll monolithic and custom releases; * in essence - Ryppl and the Boost.CMake effort. I would consider it a waste of potential to bump the version number for things of little consequence when there are things in working that have real impact on the way Boost is seen and how it is used. -- Lars Viklund | zao@acc.umu.se
Hi, On Sat, Jun 25, 2011 at 22:18, Lars Viklund <zao@acc.umu.se> wrote:
If I saw a bump of Boost to 2.x.0, I would expect that something massive and somewhat breaking has occurred, along the lines of:
* complete build system revamp, with different build methods and library naming convention;
* modularisation of boost libraries into largely standalone components, with some infrastructure to roll monolithic and custom releases;
* in essence - Ryppl and the Boost.CMake effort.
I always thought that update of all or most of libraries to take account of some important C++0x features (like adding move semantics where apropriate) would have it's part in bumping boost to 2.x . Or something related to C++0x. Joël Lamotte
participants (9)
-
Beman Dawes -
Christophe Henry -
Daniel James -
Ion Gaztañaga -
Klaim - Joël Lamotte -
Lars Viklund -
Robert Ramey -
Ruediger Berlich -
Thomas Klimpel