[1.46.1] Should we try for a point release?

From my viewpoint, the process of putting together a release is now smooth enough that I'm willing to do a point release, but...
(1) Do we have enough fixes that will be ready by, say, a week from today to make a point release worthwhile? (2) We would need to be sure that we have a procedure that ensures that fixes for the point release don't get dropped from the next full release. (3) The C++ committee meets March 21-26 in Madrid. That means there's about three weeks, say March 14 - April 3, where those of us, including me, going to that meeting will be too tied up for Boost work. That why (1) says "a week from today". --Beman

2011/2/27 Beman Dawes <bdawes@acm.org>
From my viewpoint, the process of putting together a release is now smooth enough that I'm willing to do a point release, but...
(1) Do we have enough fixes that will be ready by, say, a week from today to make a point release worthwhile?
For my library Boost.Icl, which is the single new library addition of 1.46 it would be nice to have a point release. John Reid, who is writing a wrapper application around ICL, detected a bunch of compilation problems shortly before the release of 1.46.0 so I wasn't able to merge those fixes into the release branch. Moreover there are a couple of documentation flaws that were detected within the last few days. The fixes of the bugs detected by John are already in the trunk. Should more problems arise from the release of 1.46.0 I'd be eager to fix them during the one week period. So yes, from my perspective, it would be nice to have a point release and I have improvements on the ICL that are already done or can be done within one week.
(2) We would need to be sure that we have a procedure that ensures that fixes for the point release don't get dropped from the next full release.
For ICL I see no problem here. Best regards, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de

On 2/27/2011 10:28 PM, Beman Dawes wrote:
From my viewpoint, the process of putting together a release is now smooth enough that I'm willing to do a point release, but...
(1) Do we have enough fixes that will be ready by, say, a week from today to make a point release worthwhile?
I have Proto fixes in trunk I'd like to ship. I know there's a Fusion problem that causes compile problems on msvc 8 and 7.1. Yeah, there are a number of problems we could correct.
(2) We would need to be sure that we have a procedure that ensures that fixes for the point release don't get dropped from the next full release.
Why wouldn't we just use the normal release branch? Then the changes would only need to be made once.
(3) The C++ committee meets March 21-26 in Madrid. That means there's about three weeks, say March 14 - April 3, where those of us, including me, going to that meeting will be too tied up for Boost work. That why (1) says "a week from today".
Ya. -- Eric Niebler BoostPro Computing http://www.boostpro.com

On 28 February 2011 04:27, Eric Niebler <eric@boostpro.com> wrote:
On 2/27/2011 10:28 PM, Beman Dawes wrote:
(2) We would need to be sure that we have a procedure that ensures that fixes for the point release don't get dropped from the next full release.
Why wouldn't we just use the normal release branch? Then the changes would only need to be made once.
Are we doing this? I'm away this weekend so I'll need to get my side of things sorted out pretty quickly. Daniel

On Tue, Mar 1, 2011 at 3:59 PM, Daniel James <dnljms@gmail.com> wrote:
On 28 February 2011 04:27, Eric Niebler <eric@boostpro.com> wrote:
On 2/27/2011 10:28 PM, Beman Dawes wrote:
(2) We would need to be sure that we have a procedure that ensures that fixes for the point release don't get dropped from the next full release.
Why wouldn't we just use the normal release branch? Then the changes would only need to be made once.
Are we doing this? I'm away this weekend so I'll need to get my side of things sorted out pretty quickly.
I'd like to. Would it help you if we scheduled it for the 9th? --Beman

On 1 March 2011 21:03, Beman Dawes <bdawes@acm.org> wrote:
On Tue, Mar 1, 2011 at 3:59 PM, Daniel James <dnljms@gmail.com> wrote:
Are we doing this? I'm away this weekend so I'll need to get my side of things sorted out pretty quickly.
I'd like to. Would it help you if we scheduled it for the 9th?
Yes, that'd be helpful. Although it could be a little earlier if you prefer - I'll be back on Monday. Daniel

On Tue, Mar 1, 2011 at 3:59 PM, Daniel James <dnljms@gmail.com> wrote:
On 28 February 2011 04:27, Eric Niebler <eric@boostpro.com> wrote:
On 2/27/2011 10:28 PM, Beman Dawes wrote:
(2) We would need to be sure that we have a procedure that ensures that fixes for the point release don't get dropped from the next full release.
Why wouldn't we just use the normal release branch? Then the changes would only need to be made once.
Are we doing this? I'm away this weekend so I'll need to get my side of things sorted out pretty quickly.
I'd like to. Would it help you if we scheduled it for the 9th?
Does that mean it's now allowed again to commit bug fixes to the release branch? Regards Hartmut --------------- http://boost-spirit.com

On Tue, Mar 1, 2011 at 7:13 PM, Hartmut Kaiser <hartmut.kaiser@gmail.com> wrote:
On Tue, Mar 1, 2011 at 3:59 PM, Daniel James <dnljms@gmail.com> wrote:
On 28 February 2011 04:27, Eric Niebler <eric@boostpro.com> wrote:
On 2/27/2011 10:28 PM, Beman Dawes wrote:
(2) We would need to be sure that we have a procedure that ensures that fixes for the point release don't get dropped from the next full release.
Why wouldn't we just use the normal release branch? Then the changes would only need to be made once.
Are we doing this? I'm away this weekend so I'll need to get my side of things sorted out pretty quickly.
I'd like to. Would it help you if we scheduled it for the 9th?
Does that mean it's now allowed again to commit bug fixes to the release branch?
Yes, bug fixes only. I'll post a notice in a few minutes. --Beman

Beman Dawes wrote:
On Tue, Mar 1, 2011 at 3:59 PM, Daniel James <dnljms@gmail.com> wrote:
On 28 February 2011 04:27, Eric Niebler <eric@boostpro.com> wrote:
On 2/27/2011 10:28 PM, Beman Dawes wrote:
(2) We would need to be sure that we have a procedure that ensures that fixes for the point release don't get dropped from the next full release.
Why wouldn't we just use the normal release branch? Then the changes would only need to be made once.
yeah, and while we're at it, why don't we just label it 1.47 ?
Are we doing this? I'm away this weekend so I'll need to get my side of things sorted out pretty quickly.
I'd like to. Would it help you if we scheduled it for the 9th?
--Beman _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2011/3/2 Robert Ramey <ramey@rrsd.com>:
Beman Dawes wrote:
On Tue, Mar 1, 2011 at 3:59 PM, Daniel James <dnljms@gmail.com> wrote:
On 28 February 2011 04:27, Eric Niebler <eric@boostpro.com> wrote:
On 2/27/2011 10:28 PM, Beman Dawes wrote:
(2) We would need to be sure that we have a procedure that ensures that fixes for the point release don't get dropped from the next full release.
Why wouldn't we just use the normal release branch? Then the changes would only need to be made once.
yeah, and while we're at it, why don't we just label it 1.47 ?
... because the second segment of boost versions works as a clock tick on quarters (of years). So we can estimate the age of a release and the age of boost itself from that number. Obviously we missed the opportunity to count decades with the first segment. Maybe we should increment this digit every quarter of a century ;-) ... representing the development speed in boost in a majestic manner. Cheers, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de
participants (6)
-
Beman Dawes
-
Daniel James
-
Eric Niebler
-
Hartmut Kaiser
-
Joachim Faulhaber
-
Robert Ramey