[1.34.1] Release Procedures
1.34.1 Principles and Practice ============================== We will do a 1.34.1 maintenance release to deal with a number of significant bugs that came up right after the 1.34.0 release. The plan is to release 1.34.1 within the next two weeks and then close 1.34.x development. We will be using Trac http://svn.boost.org to track 1.34.1 issues and changes. Every change to 1.34.1 requires an associated Trac ticket. I will not accept patches without Trac ticket. Furthermore for a change to be accepted the correponding Trac ticket needs to have the 1.34.1 milestone assigned. Please don't assign this milestone yourself. I will assign the milestone once it's decided it should go into 1.34.1. The deadline for submitting 1.34.1 tickets is Wednesday May 23rd 6.00 pm PST. Here is the detailed process. 1. Submit bug in Trac 2. Request 1.34.1 milestone for ticket by posting to the developer list. (please copy me directly on this one) 3. 1.34.1 milestone is assigned by Release Manager. Ticket is assigned to developer 4. Post patch referencing ticket to the developer list. (Attach patch to ticket in Trac)(please copy me directly on this one) 5. Once patch is agreed upon I'll apply it to 1.34.1. One more thing, … don't rely on me picking all the issues from the list. I'll most likely fail. Be vocal, add an issue to the tracker. Thomas -- Thomas Witt witt@acm.org
The plan is to release 1.34.1 within the next two weeks and then close 1.34.x development.
knowing at least one problem with boost 1.34.0 and gcc-4.2, which was released a few days ago, (http://svn.boost.org/trac/boost/ticket/779) i'd propose to do a full regression test with gcc-4.2 before releasing 1.34.1 ... tim -- tim@klingt.org ICQ: 96771783 http://tim.klingt.org Silence is only frightening to people who are compulsively verbalizing. William S. Burroughs
On Fri, May 18, 2007 at 11:05:26AM +0200, Tim Blechmann wrote:
The plan is to release 1.34.1 within the next two weeks and then close 1.34.x development.
knowing at least one problem with boost 1.34.0 and gcc-4.2, which was released a few days ago, (http://svn.boost.org/trac/boost/ticket/779) i'd propose to do a full regression test with gcc-4.2 before releasing 1.34.1 ...
yes, yes please. gcc 4.2 is just entered in debian/unstable and i'm pretty sure it will soon become the default compiler. having a working 1.34.1 with it would be a great thing. thanks domenico -----[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Tim Blechmann wrote:
The plan is to release 1.34.1 within the next two weeks and then close 1.34.x development.
knowing at least one problem with boost 1.34.0 and gcc-4.2, which was released a few days ago, (http://svn.boost.org/trac/boost/ticket/779) i'd propose to do a full regression test with gcc-4.2 before releasing 1.34.1 ...
FWIW, it *is* being tested against gcc 4.2 already. It just takes some time until the results actually get displayed. Note, however, that gcc 4.2 is not a target compiler for the release; it's unlikely that anyone would agree to significant code changes in order to fix any problems that might be related to gcc 4.2. Consequently, I expect the gcc 4.2 test results only to be of informational value. Regards, m
knowing at least one problem with boost 1.34.0 and gcc-4.2, which was released a few days ago, (http://svn.boost.org/trac/boost/ticket/779) i'd propose to do a full regression test with gcc-4.2 before releasing 1.34.1 ...
FWIW, it *is* being tested against gcc 4.2 already. It just takes some time until the results actually get displayed.
i see ... i just saw, that gcc-4.2 was misssing on the regression website ...
Note, however, that gcc 4.2 is not a target compiler for the release; it's unlikely that anyone would agree to significant code changes in order to fix any problems that might be related to gcc 4.2. Consequently, I expect the gcc 4.2 test results only to be of informational value.
well, i have no idea about the release procedure of boost, but if bugs are known and not hard to fix, i don't see any reason, why they shouldn't be fixed for the 1.34.1 release ... tim -- tim@klingt.org ICQ: 96771783 http://tim.klingt.org You can play a shoestring if you're sincere John Coltrane
Tim Blechmann wrote: [...]
Note, however, that gcc 4.2 is not a target compiler for the release; it's unlikely that anyone would agree to significant code changes in order to fix any problems that might be related to gcc 4.2. Consequently, I expect the gcc 4.2 test results only to be of informational value.
well, i have no idea about the release procedure of boost, but if bugs are known and not hard to fix, i don't see any reason, why they shouldn't be fixed for the 1.34.1 release ...
Possibly because every additional fix entails some risk of introducing regressions? When all's said and done it's a question of defining the scope of 1.34.1 . In my opinion the couple of weeks Thomas wrote about are way too short to add other compilers to those officially supported by 1.34.x . After all, why gcc and not Borland? Their new product is apparently due out in a few weeks time... Cheers, Nicola Musatti
On 5/18/07, Nicola Musatti <Nicola.Musatti@gmail.com> wrote:
When all's said and done it's a question of defining the scope of 1.34.1 . In my opinion the couple of weeks Thomas wrote about are way too short to add other compilers to those officially supported by 1.34.x .
Agreed. Also: Release early, release often. This way, if something doesn't make it into the next release, you don't need to wait long for the release after that. (And, sure, it isn't as simple as it sounds. lots of pros and cons to work out....) Tony
Nicola Musatti wrote:
Tim Blechmann wrote: [...]
When all's said and done it's a question of defining the scope of 1.34.1 . In my opinion the couple of weeks Thomas wrote about are way too short to add other compilers to those officially supported by 1.34.x .
I don't think we'll make 4.2 a required plattform. That being said, this will be fixed. Thomas -- Thomas Witt witt@acm.org
Thomas Witt wrote:
Nicola Musatti wrote:
Tim Blechmann wrote: [...]
When all's said and done it's a question of defining the scope of 1.34.1 . In my opinion the couple of weeks Thomas wrote about are way too short to add other compilers to those officially supported by 1.34.x .
I don't think we'll make 4.2 a required plattform. That being said, this will be fixed.
I've committed the fix, but I don't have gcc 4.2 to test. (It's refusing to build for me in cygwin because of UNIX/DOS line-end woes.) Can someone with gcc-4.2.0 installed sync the RC branch and run xpressive's tests? Thanks! -- Eric Niebler Boost Consulting www.boost-consulting.com
Eric Niebler wrote:
I've committed the fix, but I don't have gcc 4.2 to test. (It's refusing to build for me in cygwin because of UNIX/DOS line-end woes.) Can someone with gcc-4.2.0 installed sync the RC branch and run xpressive's tests?
I started another cycle, in the hope generation of result tables will get re-enabled soon. Regards, m
on Sun May 20 2007, Eric Niebler <eric-AT-boost-consulting.com> wrote:
Thomas Witt wrote:
Nicola Musatti wrote:
Tim Blechmann wrote: [...]
When all's said and done it's a question of defining the scope of 1.34.1 . In my opinion the couple of weeks Thomas wrote about are way too short to add other compilers to those officially supported by 1.34.x .
I don't think we'll make 4.2 a required plattform. That being said, this will be fixed.
I've committed the fix, but I don't have gcc 4.2 to test. (It's refusing to build for me in cygwin because of UNIX/DOS line-end woes.)
Hm, I've never seen that. ./configure --prefix=/usr/local/gcc-4.2 --enable-languages=c,c++ make make install ? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
on Sun May 20 2007, Eric Niebler <eric-AT-boost-consulting.com> wrote:
Thomas Witt wrote:
Nicola Musatti wrote:
Tim Blechmann wrote: [...]
When all's said and done it's a question of defining the scope of 1.34.1 . In my opinion the couple of weeks Thomas wrote about are way too short to add other compilers to those officially supported by 1.34.x . I don't think we'll make 4.2 a required plattform. That being said, this will be fixed. I've committed the fix, but I don't have gcc 4.2 to test. (It's refusing to build for me in cygwin because of UNIX/DOS line-end woes.)
Hm, I've never seen that.
./configure --prefix=/usr/local/gcc-4.2 --enable-languages=c,c++ make make install
?
As I said, it doesn't work on cygwin for me because of line ending problems. It does things like "echo stage3 > stage_final", and elsewhere uses `stage_final`-sometag, which doesn't generate a proper identifier because of the \r\n at the end of the stage_final file. -- Eric Niebler Boost Consulting www.boost-consulting.com
on Fri May 18 2007, Tim Blechmann <tim-AT-klingt.org> wrote:
The plan is to release 1.34.1 within the next two weeks and then close 1.34.x development.
knowing at least one problem with boost 1.34.0 and gcc-4.2, which was released a few days ago, (http://svn.boost.org/trac/boost/ticket/779) i'd propose to do a full regression test with gcc-4.2 before releasing 1.34.1 ...
Why not enter a Trac ticket for that? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
Thomas Witt wrote:
Here is the detailed process.
1. Submit bug in Trac 2. Request 1.34.1 milestone for ticket by posting to the developer list. (please copy me directly on this one) 3. 1.34.1 milestone is assigned by Release Manager. Ticket is assigned to developer 4. Post patch referencing ticket to the developer list. (Attach patch to ticket in Trac)(please copy me directly on this one) 5. Once patch is agreed upon I'll apply it to 1.34.1.
Earlier you've said it's OK to apply cygwin building patch (which is now #966). That issues has a link to a patch, and now you say you'll be applying all agreed-upon patches. Am I right that you're gonna apply that patch? - Volodya
Vladimir Prus wrote:
Thomas Witt wrote:
Earlier you've said it's OK to apply cygwin building patch (which is now #966). That issues has a link to a patch, and now you say you'll be applying all agreed-upon patches.
Me applying the patch is the default. I may still ask you to apply the patch for me, in order to reduce my workload and speed things up;-). So please don't apply patches unless asked and please do apply patches in case I ask for it.
Am I right that you're gonna apply that patch?
I would be thankful if you could do it in this case. Thanks Thomas -- Thomas Witt witt@acm.org
participants (9)
-
David Abrahams -
Domenico Andreoli -
Eric Niebler -
Gottlob Frege -
Martin Wille -
Nicola Musatti -
Thomas Witt -
Tim Blechmann -
Vladimir Prus