1.58.1 bugfix release necessary?

newer
[Property Tree] No documentation...

Oliver Kowalke

22 Apr 2015 22 Apr '15

4:59 p.m.

Unfortunately boost.context fails to compile for gcc-4.8.x and option -std=c++11. Because of a dependency to boost.context, boost.asio and boost.coroutine do not compile too. I've pushed a pull-request to boost.config - the patch adds C++14 test macro BOOST_NO_CXX14_INTEGER_SEQUENCE ( https://github.com/boostorg/config/pull/57). Oliver

Show replies by date

Robert Ramey

22 Apr 22 Apr

5:26 p.m.

The test matrix http://www.boost.org/development/tests/develop/developer/serialization.html doesn't consistently show which version of C++ the test runs correspond to. Perhaps this can be improved. This would make it easier to identify situations like this sooner. It might also be helpful if the test results were organized by platform/version e.g. win32/c++0x, etc. I have no idea what this might entail - it's only a suggestion. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/1-58-1-bugfix-release-necessary-tp4674686... Sent from the Boost - Dev mailing list archive at Nabble.com.

John Maddock

5:52 p.m.

On 22/04/2015 18:26, Robert Ramey wrote:

...

The test matrix http://www.boost.org/development/tests/develop/developer/serialization.html

doesn't consistently show which version of C++ the test runs correspond to. Perhaps this can be improved. This would make it easier to identify situations like this sooner. I'm sure I must have mentioned this before, but whenever you see a test failure, and you're not sure what the compiler version / setup is, lets say for example you wanted more information on http://www.boost.org/development/tests/develop/developer/output/Qt5-4%20jc-b...

then go to the Boost.Config results, and look for the "config_info" results for the same compiler, this will tell you (hopefully!) everything you could want to know about the compiler, platform, stdlib, and Boost.Config: http://www.boost.org/development/tests/develop/developer/output/Qt5-4%20jc-b... There is also "math_info" which does the same thing for the contents of <limits> and <climits> : http://www.boost.org/development/tests/develop/developer/output/Qt5-4%20jc-b... HTH, John.

Rene Rivera

7:21 p.m.

On Wed, Apr 22, 2015 at 12:52 PM, John Maddock wrote:

...

On 22/04/2015 18:26, Robert Ramey wrote:

...
The test matrix

http://www.boost.org/development/tests/develop/developer/serialization.html

doesn't consistently show which version of C++ the test runs correspond to. Perhaps this can be improved. This would make it easier to identify situations like this sooner.

I'm sure I must have mentioned this before, but whenever you see a test failure, and you're not sure what the compiler version / setup is, lets say for example you wanted more information on http://www.boost.org/development/tests/develop/developer/output/Qt5-4%20jc-b...

then go to the Boost.Config results, and look for the "config_info" results for the same compiler, this will tell you (hopefully!) everything you could want to know about the compiler, platform, stdlib, and Boost.Config: http://www.boost.org/development/tests/develop/developer/output/Qt5-4%20jc-b...

There is also "math_info" which does the same thing for the contents of <limits> and <climits> : http://www.boost.org/development/tests/develop/developer/output/Qt5-4%20jc-b...

And there's also the information from Predef which, although less comprehensive, does give you more platform info, i.e. compiler and OS < http://www.boost.org/development/tests/develop/developer/output/Qt5-4%20jc-b...

...

.

-- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

John Maddock

6:25 p.m.

...

Unfortunately boost.context fails to compile for gcc-4.8.x and option -std=c++11. Because of a dependency to boost.context, boost.asio and boost.coroutine do not compile too. I've pushed a pull-request to boost.config - the patch adds C++14 test macro BOOST_NO_CXX14_INTEGER_SEQUENCE ( https://github.com/boostorg/config/pull/57). Oliver, I've just rejected that one as it doesn't quite add things in

the right way - sorry! However, I will add the macro at some point, probably sooner rather than later with a PR, but I promise to try and get there... I confess there are a couple of other Config issues, plus one multiprecision bug fix that could go in a .1 release should we decide to have one. And did we get the python issues fully sorted out or are there issues there as well? Cheers, John.

Jason Roehm

6:29 p.m.

On 04/22/2015 02:25 PM, John Maddock wrote:

...

...
Unfortunately boost.context fails to compile for gcc-4.8.x and option -std=c++11. Because of a dependency to boost.context, boost.asio and boost.coroutine do not compile too. I've pushed a pull-request to boost.config - the patch adds C++14 test macro BOOST_NO_CXX14_INTEGER_SEQUENCE ( https://github.com/boostorg/config/pull/57). Oliver, I've just rejected that one as it doesn't quite add things in the right way - sorry!

However, I will add the macro at some point, probably sooner rather than later with a PR, but I promise to try and get there...

I confess there are a couple of other Config issues, plus one multiprecision bug fix that could go in a .1 release should we decide to have one.

Strictly from a Boost user's perspective, the Context (and therefore Coroutine, ASIO) build problem is a pretty serious one. gcc-4.8.x / C++11 is a pretty mainstream configuration nowadays. At the very least, the publishing of a patch file on boost.org as has been done in the past would be appreciated in order to enable building with this compiler configuration. Jason

Damien Buhl

7:09 p.m.

‎Hi, As you may have seen in thread "‎Re: [boost] [Boost-bugs] Fwd: [Boost C++ Libraries] #11211: Fusion example no longer compiles"‎. We also have a really serious issue in Boost 1.58 with Fusion on any compiler with constexpr support (that is when C++11 is enabled). The macro BOOST_FUSION_DEFINE_STRUCT fails to compile with non constant expression compatible types. This is a terrible issue, because most of the people using spirit uses BOOST_FUSION_DEFINE_STRUCT. We already merged a bugfix on master, we however have to check that the others DEFINE macros aren't affected. Cheers, -- Damien Buhl Sent from my BlackBerry, please excuse my brevity Original Message From: Jason Roehm Sent: mercredi 22 avril 2015 20:29 To: boost@lists.boost.org Reply To: boost@lists.boost.org Subject: Re: [boost] 1.58.1 bugfix release necessary? On 04/22/2015 02:25 PM, John Maddock wrote:

...

...
Unfortunately boost.context fails to compile for gcc-4.8.x and option -std=c++11. Because of a dependency to boost.context, boost.asio and boost.coroutine do not compile too. I've pushed a pull-request to boost.config - the patch adds C++14 test macro BOOST_NO_CXX14_INTEGER_SEQUENCE ( https://github.com/boostorg/config/pull/57). Oliver, I've just rejected that one as it doesn't quite add things in the right way - sorry!

However, I will add the macro at some point, probably sooner rather than later with a PR, but I promise to try and get there...

I confess there are a couple of other Config issues, plus one multiprecision bug fix that could go in a .1 release should we decide to have one.

Domagoj Saric

7:49 p.m.

And there's also this: https://svn.boost.org/trac/boost/ticket/11181 (TypeErasure is broken on MSVC in 1.56, 1.57 and 1.58...) -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman

Oliver Kowalke

23 Apr 23 Apr

7:01 a.m.

2015-04-22 20:25 GMT+02:00 John Maddock :

...

Oliver, I've just rejected that one as it doesn't quite add things in the right way - sorry!

new pull-request - https://github.com/boostorg/config/pull/58

Rüdiger Berlich

7:38 a.m.

Hi, I know everyone has his/her favorite bug. However this: https://svn.boost.org/trac/boost/ticket/11214 https://svn.boost.org/trac/boost/ticket/11214 really prevents me from recommending users of our (optimization)library to use Boost 1.58 , as de-serialized objects may have wrong content. So a 1.58.1 bugfix release would really help! Best Regards, Beet

...

Am 22.04.2015 um 18:59 schrieb Oliver Kowalke :

Unfortunately boost.context fails to compile for gcc-4.8.x and option -std=c++11. Because of a dependency to boost.context, boost.asio and boost.coroutine do not compile too. I've pushed a pull-request to boost.config - the patch adds C++14 test macro BOOST_NO_CXX14_INTEGER_SEQUENCE ( https://github.com/boostorg/config/pull/57).

Oliver

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Ion Gaztañaga

25 Apr 25 Apr

9:59 p.m.

El 23/04/2015 a las 9:38, Rüdiger Berlich escribió:

...

Hi,

I know everyone has his/her favorite bug. However this: https://svn.boost.org/trac/boost/ticket/11214 https://svn.boost.org/trac/boost/ticket/11214 really prevents me from recommending users of our (optimization)library to use Boost 1.58 , as de-serialized objects may have wrong content.

So a 1.58.1 bugfix release would really help!

I also have one or two bugs in Boost.Move that could be great for 1.58.1, so definitely interested. Ion

Robert Ramey

26 Apr 26 Apr

1:38 p.m.

What is would be the difference between creating a bug fix release presumably called 1.58.1 and just expediting release 1.59 ? The work is the same and this would be less confusion as we wouldn't have any "branching structure" which would tempt people to treat the "branches" differently. I believe the best way to address problems of this nature is to a) test better - more testing is better b) release more frequently - would diminish the incentive to cut corners to get something in the release Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/1-58-1-bugfix-release-necessary-tp4674686... Sent from the Boost - Dev mailing list archive at Nabble.com.

Tim Blechmann

3:55 p.m.

...

What is would be the difference between creating a bug fix release presumably called 1.58.1 and just expediting release 1.59 ? The work is the same and this would be less confusion as we wouldn't have any "branching structure" which would tempt people to treat the "branches" differently.

I believe the best way to address problems of this nature is to

a) test better - more testing is better

no matter how much testing will be done, we can never achieve the test coverage that we will have when the code will be used in real-world projects.

...

b) release more frequently - would diminish the incentive to cut corners to get something in the release

releasing more frequent will also mean that commits will also reduce the average time between a commit hits 'master' and being released ... also new releases always have the risk of introducing new bugs. the notion of a 'bugfix' release is: bugfix *only*, no new features. also: more frequent updates won't especially help linux users that use the boost version bundled with their distribution: e.g. ubuntu-14.10 ships 1.55, while we are at 1.58 ...

John Maddock

4:33 p.m.

On 26/04/2015 14:38, Robert Ramey wrote:

...

What is would be the difference between creating a bug fix release presumably called 1.58.1 and just expediting release 1.59 ?

A bugfix release is exactly that - bug fixes only, no new features or new libraries. If we go that route then we already have the beta for 1.58.1: it's called 1.58.0. So we could allow low risk bugfixes for a limited time, and then go straight to a release candidate. John.

Robert Ramey

5:58 p.m.

John Maddock-2 wrote

...

On 26/04/2015 14:38, Robert Ramey wrote:

...
What is would be the difference between creating a bug fix release presumably called 1.58.1 and just expediting release 1.59 ?

A bugfix release is exactly that - bug fixes only, no new features or new libraries.

If we do that, then we'll have to create a new branch since there's already new stuff in master. Now we'll have to retest the "bug fix" release. And, we'll have to make sure that all the bug fixes get merged back into the master from from which the next release is going to be derived. Seems to me a lot of work when the same effort could be applied to the next release.

...

If we go that route then we already have the beta for 1.58.1: it's called 1.58.0. So we could allow low risk bugfixes for a limited time, and then go straight to a release candidate.

I'm not sure I understand that. But one thing we could do is leave the beta out there for testing longer. Right now we put it out there and ask people to try to install it and test it. I understand how they install it, but I'm not sure how they test it. We don't have a widely used/promoted procedure for testing one's release on one's own machine (do we?). Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/1-58-1-bugfix-release-necessary-tp4674686... Sent from the Boost - Dev mailing list archive at Nabble.com.

Klaim - Joël Lamotte

11:11 p.m.

On Sun, Apr 26, 2015 at 7:58 PM, Robert Ramey wrote:

...

John Maddock-2 wrote

...
On 26/04/2015 14:38, Robert Ramey wrote:

...
What is would be the difference between creating a bug fix release presumably called 1.58.1 and just expediting release 1.59 ?

A bugfix release is exactly that - bug fixes only, no new features or new libraries.

If we do that, then we'll have to create a new branch since there's already new stuff in master. Now we'll have to retest the "bug fix" release. And, we'll have to make sure that all the bug fixes get merged back into the master from from which the next release is going to be derived.

Seems to me a lot of work when the same effort could be applied to the next release.

Iff the system currently used to manage master and develop branches can be reused for another branch, it could be easier than one might expect. I don't know how it is implemented currently though (except that there is some kind of bot doing stuffs depending on branches from submodules). In the bugfix branch scenario: There would be a new specific branch for the bugfix version, say "bugfix/1.58.1" created in the root repository, then each library author would decide if they have something to put in that bugfix release. If yes, they would create the same branch for their library repository (as they do for develop and master). For fixes already commited in their develop/master branches, they would "cherry-pick" commits into the bugfix branch where it's ok to do so, or just duplicate bugfixes. Otherwise they would do specific bugfix commitsfor for that specific release (for example if it's a temporary workaround that will be changed in the develop/master branch later). When the release time is ready, the same process to release the master branch would occur, but using the bugfix/1.58.1 branch instead. This is actually a pretty common pattern when using decentralized control sources (it's more or less how gitflow works), although most of the time it happen with only one repository, so the work to allow this way of doing bugfix releases might be more work if the release tools are not flexible enough (yet). I don't know if it would be a problem in the case of boost to allow this but it would be convenient for a lot of users (including myself and the company I work for). Because it would mean that there can be stable api release with only bugfixes, instead of bugfixes releases with potential additional api-breaking changes. If library authors are not forced to provide bugfix releases but have a chance to do it if they want (which is not the case currently) and if it's not hard to setup (I don't have a clear idea about that), it would certainly be a good thing.

...

...
If we go that route then we already have the beta for 1.58.1: it's called 1.58.0. So we could allow low risk bugfixes for a limited time, and then go straight to a release candidate.

I'm not sure I understand that. But one thing we could do is leave the beta out there for testing longer. Right now we put it out there and ask people to try to install it and test it. I understand how they install it, but I'm not sure how they test it. We don't have a widely used/promoted procedure for testing one's release on one's own machine (do we?).

Robert Ramey

-- View this message in context: http://boost.2283326.n4.nabble.com/1-58-1-bugfix-release-necessary-tp4674686... Sent from the Boost - Dev mailing list archive at Nabble.com.

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Michael Caisse

27 Apr 27 Apr

2:56 a.m.

On 04/26/2015 10:58 AM, Robert Ramey wrote:

...

John Maddock-2 wrote

...
On 26/04/2015 14:38, Robert Ramey wrote:

...
What is would be the difference between creating a bug fix release presumably called 1.58.1 and just expediting release 1.59 ?

A bugfix release is exactly that - bug fixes only, no new features or new libraries.

If we do that, then we'll have to create a new branch since there's already new stuff in master. Now we'll have to retest the "bug fix" release. And, we'll have to make sure that all the bug fixes get merged back into the master from from which the next release is going to be derived.

Seems to me a lot of work when the same effort could be applied to the next release.

This is how "git flow" works. It isn't a lot of work and it greatly reduces risk. While we let authors control their repositories mostly in whichever manner they wish, it would be prudent to follow the branching model here http://nvie.com/posts/a-successful-git-branching-model/. Unless the author already has substantial and practical experience with Git, using a well-tested work flow is going to be the best pattern for success. michael -- Michael Caisse ciere consulting ciere.com

ruediger

26 Apr 26 Apr

8:05 p.m.

Hi there,

...

Am 26.04.2015 um 15:38 schrieb Robert Ramey :

What is would be the difference between creating a bug fix release presumably called 1.58.1 and just expediting release 1.59 ?

From a Linux user's perspective: A 1.58 would never ship with one of the common Linux distributions, if a 1.58.1 were available. But it might, if a 1.58 would not exist. Best Regards, Beet

...

The work is the same and this would be less confusion as we wouldn't have any "branching structure" which would tempt people to treat the "branches" differently.

I believe the best way to address problems of this nature is to

a) test better - more testing is better b) release more frequently - would diminish the incentive to cut corners to get something in the release

Robert Ramey

-- View this message in context: http://boost.2283326.n4.nabble.com/1-58-1-bugfix-release-necessary-tp4674686... Sent from the Boost - Dev mailing list archive at Nabble.com.

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Robert Ramey

8:54 p.m.

beet-2 wrote

...

Hi there,

...
Am 26.04.2015 um 15:38 schrieb Robert Ramey <

...

ramey@

...

>:

...
What is would be the difference between creating a bug fix release presumably called 1.58.1 and just expediting release 1.59 ?

From a Linux user's perspective: A 1.58 would never ship with one of the common Linux distributions, if a 1.58.1 were available. But it might, if a 1.58 would not exist.

Hmmm - if 1.59 were available - would 1.58 ship? Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/1-58-1-bugfix-release-necessary-tp4674686... Sent from the Boost - Dev mailing list archive at Nabble.com.

Tim Blechmann

27 Apr 27 Apr

5:18 a.m.

...

...
...
What is would be the difference between creating a bug fix release presumably called 1.58.1 and just expediting release 1.59 ?

From a Linux user's perspective: A 1.58 would never ship with one of the common Linux distributions, if a 1.58.1 were available. But it might, if a 1.58 would not exist.

Hmmm - if 1.59 were available - would 1.58 ship?

ubuntu 15.04 was released this month and provides boost 1.55. if 1.59 is released (or packaged) after the 'feature freeze', it will not be allowed to go in. if 1.58 is packaged and 1.58.1 is released after the 'feature freeze', it will go in as bugfix.

Andrey Semashev

9:09 a.m.

On Monday 27 April 2015 07:18:39 Tim Blechmann wrote:

...

...
...
...
What is would be the difference between creating a bug fix release presumably called 1.58.1 and just expediting release 1.59 ?

From a Linux user's perspective: A 1.58 would never ship with one of the common Linux distributions, if a 1.58.1 were available. But it might, if a 1.58 would not exist.

Hmmm - if 1.59 were available - would 1.58 ship?

ubuntu 15.04 was released this month and provides boost 1.55.

if 1.59 is released (or packaged) after the 'feature freeze', it will not be allowed to go in. if 1.58 is packaged and 1.58.1 is released after the 'feature freeze', it will go in as bugfix.

That is actually up to the distro maintainers to decide. It is typical that no new releases of software are allowed into the frozen distro release unless there is a serious problem, and the fix cannot be easily backported to the selected upstream release. In binary distros it is not uncommon to have a number of patches over the official upstream release of the software in order to fix bugs and adjust to the distro environment. So Boost 1.55 in Ubuntu is most certainly not the 1.55 we released and the same will be with any other release we ship. I think the best we can do to fix 1.58 with our current workflow is to publish patches that fix known problems in the 1.58 release notes. That way it will be easier for the distro maintainers to find essential fixes. This did help in the past with Ubuntu, at least.

3501

Age (days ago)

3506

Last active (days ago)

List overview

Download

20 comments

14 participants

participants (14)

Andrey Semashev
Damien Buhl
Domagoj Saric
Ion Gaztañaga
Jason Roehm
John Maddock
Klaim - Joël Lamotte
Michael Caisse
Oliver Kowalke
Rene Rivera
Robert Ramey
ruediger
Rüdiger Berlich
Tim Blechmann