John Maddock recently complained that "beta's are too short". I agree, since we end up not having time to do more that a few high priority fixes. How long should we allow between the time the beta actually becomes available and closing branches/release prior to release? Should we adjust the 1.46.0 schedule accordingly? --Beman
On Thu, Feb 3, 2011 at 7:14 AM, Beman Dawes <bdawes@acm.org> wrote:
John Maddock recently complained that "beta's are too short". I agree, since we end up not having time to do more that a few high priority fixes.
How long should we allow between the time the beta actually becomes available and closing branches/release prior to release?
How long is it currently? -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On 3 February 2011 12:58, Dave Abrahams <dave@boostpro.com> wrote:
On Thu, Feb 3, 2011 at 7:14 AM, Beman Dawes <bdawes@acm.org> wrote:
John Maddock recently complained that "beta's are too short". I agree, since we end up not having time to do more that a few high priority fixes.
How long should we allow between the time the beta actually becomes available and closing branches/release prior to release?
How long is it currently?
2 weeks. Schedule: https://svn.boost.org/trac/boost/wiki/ReleaseSchedule Calendar: http://www.boost.org/development/ Daniel
At Thu, 3 Feb 2011 13:06:09 +0000, Daniel James wrote:
On 3 February 2011 12:58, Dave Abrahams <dave@boostpro.com> wrote:
On Thu, Feb 3, 2011 at 7:14 AM, Beman Dawes <bdawes@acm.org> wrote:
John Maddock recently complained that "beta's are too short". I agree, since we end up not having time to do more that a few high priority fixes.
How long should we allow between the time the beta actually becomes available and closing branches/release prior to release?
How long is it currently?
2 weeks.
My gut said a month is a minimum. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On 3 February 2011 15:29, Dave Abrahams <dave@boostpro.com> wrote:
2 weeks.
My gut said a month is a minimum.
What do you think the period between closing for new libraries/major/minor changes and the start of the beta should be? I also wonder how well people feel the distinction between different types of changes works. Daniel
At Thu, 3 Feb 2011 15:51:04 +0000, Daniel James wrote:
On 3 February 2011 15:29, Dave Abrahams <dave@boostpro.com> wrote:
2 weeks.
My gut said a month is a minimum.
What do you think the period between closing for new libraries/major/minor changes and the start of the beta should be? I also wonder how well people feel the distinction between different types of changes works.
My gut talking again: a few days at most. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Thu, Feb 3, 2011 at 4:56 PM, Dave Abrahams <dave@boostpro.com> wrote:
At Thu, 3 Feb 2011 15:51:04 +0000, Daniel James wrote:
On 3 February 2011 15:29, Dave Abrahams <dave@boostpro.com> wrote:
2 weeks.
My gut said a month is a minimum.
What do you think the period between closing for new libraries/major/minor changes and the start of the beta should be? I also wonder how well people feel the distinction between different types of changes works.
My gut talking again: a few days at most.
There used to be a bunch of manual steps in building a release, beta or otherwise, and many were error prone or subject to difficult to diagnose failures. So we built a long time into the schedule for building releases. Now the steps all mostly automated via scripts, and rarely have any problems. There needs to be say two days in there to give tests a chance to cycle to make sure a late change didn't totally screw up lots of libraries. If we had a way to lock release tests into a particular revision, we wouldn't need any delay at all. --Beman
Beman Dawes wrote:
John Maddock recently complained that "beta's are too short". I agree, since we end up not having time to do more that a few high priority fixes.
FWIW - this another opportunity to plug my proposal that testing of each library be done against the current release branch. (that is the candidate for the next release). I would hope that this diminishes the differences which would be pending between the beta and final version. In effect, testing would be applied to the "beta" on a continuing basis. Anyone who want's to test the "beta" would only have to sync his local system to the release branch. That is a lot of the current beta testing would be built into the library development. I apologize for constantly nagging on this. I just think that opportunities for pointing out the benefits of doing this just keep presenting themselves and I can't restrain myself. Robert Ramey
participants (4)
-
Beman Dawes -
Daniel James -
Dave Abrahams -
Robert Ramey