So.... it looks like we have a number of small niggles, not least of which is the shared_ptr problem, so do we go for a 1.33.1 release? Assuming "yes", can everyone who's made changes to the RC_1_33_0 branch, please make sure that those fixes are logged in the news section of index.htm. I've added preliminary entries for config, shared_ptr and regex, but the following libs also have changes: hash, iostreams parameter program_options serialization test The plan then would be to produce an early *beta* of the tarballs/zips sometime soon (I may be able to do this on Saturday), this would act as an initial hotfix release as well as the first beta: we can then move on to a fairly leisurely cycle (two weeks or so?) of one or two more betas, followed by a final 1.33.1 release. The aim would be to: * Give lib authors more time to fix any issues that may have come up. * Test a beta release procedure and see how it works out. * Give uses a little more time to report critical issues that still need fixing, but aren't in the Beta. We also need to decide how much of our testing resources to devote to testing 1.33.1: this is the biggest argument against another release, we do not want to stall main branch development. How does this sound to everyone? John.
John Maddock wrote:
So.... it looks like we have a number of small niggles, not least of which is the shared_ptr problem, so do we go for a 1.33.1 release?
Assuming "yes", can everyone who's made changes to the RC_1_33_0 branch, please make sure that those fixes are logged in the news section of index.htm.
I've added preliminary entries for config, shared_ptr and regex, but the following libs also have changes:
hash, iostreams parameter program_options
The program_options library has a single change on branch, which is fixed link in docs. I think that does not deserve a mention in news section. - Volodya
On Aug 24, 2005, at 7:45 AM, Jeff Garland wrote:
On Wed, 24 Aug 2005 12:55:50 +0100, John Maddock wrote
How does this sound to everyone?
Sounds good -- there's a couple small changes for date-time.
Will this release have fixes in for Tiger 10.4.2 and gcc 4.0? Last I checked there were still a few tests (compose_test is one I recall), that hang at runtime. -- Noel
Jeff Garland wrote:
there's a couple small changes for date-time.
I have some performance tweaks for date-time. Basically, tokenizer is replaced with faster token_iterator, convert_to_lower() converts inplace instead of copying. I wonder if boost::algorithm::tolower() should be used instead of convert_to_lower(). Unfortunately I don't have time to prepare the diff yet, because I need to separate the right changes from dirty hacks I used to squeeze some more speed or to support parsing broken date formats. Andrey
On Aug 24, 2005, at 6:55 AM, John Maddock wrote:
So.... it looks like we have a number of small niggles, not least of which is the shared_ptr problem, so do we go for a 1.33.1 release?
Sure.
The aim would be to:
* Give lib authors more time to fix any issues that may have come up. * Test a beta release procedure and see how it works out. * Give uses a little more time to report critical issues that still need fixing, but aren't in the Beta.
Depending on our intended schedule, we could also introduce a few new compilers as release compilers, e.g., GCC 4.0 on Mac OS X and Intel 9.0 on Linux. Doug
On Aug 24, 2005, at 9:17 AM, Markus Schöpflin wrote:
Douglas Gregor wrote:
Depending on our intended schedule, we could also introduce a few new compilers as release compilers, e.g., GCC 4.0 on Mac OS X and Intel 9.0 on Linux.
cxx on Tru64?
I'm concerned that we are not getting feedback fast enough for cxx on Tru64. Both the COMSOFT and HP TestDrive tests are 3 days old now. Without a 1-2 day turnaround time on regression tests, we can't adequately address compiler- and platform-specific problems without slowing down the release cycle. Doug
Doug Gregor wrote:
On Aug 24, 2005, at 9:17 AM, Markus Schöpflin wrote:
cxx on Tru64?
I'm concerned that we are not getting feedback fast enough for cxx on Tru64. Both the COMSOFT and HP TestDrive tests are 3 days old now. Without a 1-2 day turnaround time on regression tests, we can't adequately address compiler- and platform-specific problems without slowing down the release cycle.
The TestDrive test are currently switched off because I'm waiting for installation of the final 7.1 release on the machine. The tests at COMSOFT took so long because I was starting a new run with a new configuration, they should be updating about once a day now. But anyway, I will be away next week therefore I won't be available to do a switch to the release branch. If the release has not happended by then, maybe you should reconsider your position because the tests on Tru64 are in pretty good shape, they would only need some expected failure markups. Markus
Douglas Gregor wrote:
Depending on our intended schedule, we could also introduce a few new compilers as release compilers, e.g., GCC 4.0 on Mac OS X and Intel 9.0 on Linux.
Would you be interested in this patch for "DragonFly" (http://www.dragonflybsd.org/main/) from one of LyX's users? http://article.gmane.org/gmane.editors.lyx.devel/47653 The patch is against Boost 1.32. Regards, Angus
Would you be interested in this patch for "DragonFly" (http://www.dragonflybsd.org/main/) from one of LyX's users?
Yep, applied, thanks, John.
Depending on our intended schedule, we could also introduce a few new compilers as release compilers, e.g., GCC 4.0 on Mac OS X and Intel 9.0 on Linux.
We really need to apply this patch as well (http://lists.boost.org/Archives/boost/2005/07/90101.php), I was planning on applying it to the main branch today, and then if there are no regressions, adding it to the release branch as well. However for some reason I can't get cygwin patch to play ball and apply the patch without getting asked for a filename for every file patched (and there are a lot of them!), anyone have any ideas, or able to apply this? Thanks, John.
hi, On Wed, Aug 24, 2005 at 12:55:50PM +0100, John Maddock wrote:
So.... it looks like we have a number of small niggles, not least of which is the shared_ptr problem, so do we go for a 1.33.1 release?
...
How does this sound to everyone?
i'm re-proposing a patch rejected by Doug because of the imminent release of 1.33.0 [0]. it is the result of some bug fixes against boost debian packaged. regards domenico [0] http://aspn.activestate.com/ASPN/Mail/Message/boost/2759975 -----[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
On Aug 24, 2005, at 11:17 AM, Domenico Andreoli wrote:
hi,
On Wed, Aug 24, 2005 at 12:55:50PM +0100, John Maddock wrote:
So.... it looks like we have a number of small niggles, not least of which is the shared_ptr problem, so do we go for a 1.33.1 release?
...
How does this sound to everyone?
i'm re-proposing a patch rejected by Doug because of the imminent release of 1.33.0 [0]. it is the result of some bug fixes against boost debian packaged.
Okay, done! Doug
John Maddock wrote:
So.... it looks like we have a number of small niggles, not least of which is the shared_ptr problem, so do we go for a 1.33.1 release?
Assuming "yes", can everyone who's made changes to the RC_1_33_0 branch, please make sure that those fixes are logged in the news section of index.htm.
I've added preliminary entries for config, shared_ptr and regex, but the following libs also have changes: [...]
I don't see them in the CVS index.htm... maybe you committed to the branch? They should go to HEAD, I guess.
I don't see them in the CVS index.htm... maybe you committed to the branch? They should go to HEAD, I guess.
Yes that change is on the branch only: I wanted to ensure that the fixes added to 1.33.1 would be documented. I don't see any great need for these to be added to HEAD as well, or at least not yet anyway? John.
On Aug 25, 2005, at 4:30 AM, John Maddock wrote:
I don't see them in the CVS index.htm... maybe you committed to the branch? They should go to HEAD, I guess.
Yes that change is on the branch only: I wanted to ensure that the fixes added to 1.33.1 would be documented. I don't see any great need for these to be added to HEAD as well, or at least not yet anyway?
We can easily merge the changes back into HEAD from the 1.33.1 branch. Doug
I'd like to have mersenne_twister support serialization. Trivial, harmless patch is all that's needed.
"John Maddock" <john@johnmaddock.co.uk> writes:
So.... it looks like we have a number of small niggles, not least of which is the shared_ptr problem, so do we go for a 1.33.1 release?
Assuming "yes", can everyone who's made changes to the RC_1_33_0 branch, please make sure that those fixes are logged in the news section of index.htm.
I've added preliminary entries for config, shared_ptr and regex, but the following libs also have changes:
hash, iostreams parameter
?? Parameter shouldn't have any code changes on the RC_1_33_0 branch. Does it? I believe there are just minor editorial changes to the docs, that don't merit change entries.
program_options serialization
-- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (5)
-
Andrey Melnikov -
Angus Leeming -
David Abrahams -
Domenico Andreoli -
Doug Gregor -
Douglas Gregor -
Jeff Garland -
John Maddock -
Jonathan Turkanis -
Markus Schöpflin -
Markus Schöpflin -
Neal Becker -
Noel Belcourt -
Peter Dimov -
Vladimir Prus