1.58.1 bugfix release necessary?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

1.58.1 bugfix release necessary?

Oliver Kowalke-3
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
Reply | Threaded
Open this post in threaded view
|

Re: 1.58.1 bugfix release necessary?

Robert Ramey
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
Reply | Threaded
Open this post in threaded view
|

Re: 1.58.1 bugfix release necessary?

John Maddock-2


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-bell-boost-bin-v2-libs-serialization-test-test_array_binary_archive-test-gcc-mingw-4-9-1-debug.html

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-bell-boost-bin-v2-libs-config-test-config_info-test-gcc-mingw-4-9-1-debug.html

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-bell-boost-bin-v2-libs-config-test-math_info-test-gcc-mingw-4-9-1-debug.html

HTH, John.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: 1.58.1 bugfix release necessary?

John Maddock-2
In reply to this post by Oliver Kowalke-3

> 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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: 1.58.1 bugfix release necessary?

Jason
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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: 1.58.1 bugfix release necessary?

damien.buhl@lecbna.org
‎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: [hidden email]
Reply To: [hidden email]
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.

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


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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: 1.58.1 bugfix release necessary?

Rene Rivera-2
In reply to this post by John Maddock-2
On Wed, Apr 22, 2015 at 12:52 PM, John Maddock <[hidden email]>
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-bell-boost-bin-v2-libs-serialization-test-test_array_binary_archive-test-gcc-mingw-4-9-1-debug.html
>
> 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-bell-boost-bin-v2-libs-config-test-config_info-test-gcc-mingw-4-9-1-debug.html
>
> 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-bell-boost-bin-v2-libs-config-test-math_info-test-gcc-mingw-4-9-1-debug.html


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-bell-boost-bin-v2-libs-predef-test-info_as_cpp-test-gcc-mingw-4-9-1-debug.html
>.

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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: 1.58.1 bugfix release necessary?

Domagoj Saric-2
In reply to this post by damien.buhl@lecbna.org
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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: 1.58.1 bugfix release necessary?

Oliver Kowalke-3
In reply to this post by John Maddock-2
2015-04-22 20:25 GMT+02:00 John Maddock <[hidden email]>:

>
> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: 1.58.1 bugfix release necessary?

Rüdiger Berlich
In reply to this post by Oliver Kowalke-3
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 <[hidden email]>:
>
> 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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: 1.58.1 bugfix release necessary?

Ion Gaztañaga
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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: 1.58.1 bugfix release necessary?

Robert Ramey
In reply to this post by Oliver Kowalke-3
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
Reply | Threaded
Open this post in threaded view
|

Re: 1.58.1 bugfix release necessary?

Tim Blechmann-2
> 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 ...



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: 1.58.1 bugfix release necessary?

John Maddock-2
In reply to this post by Robert Ramey


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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: 1.58.1 bugfix release necessary?

Robert Ramey
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
Reply | Threaded
Open this post in threaded view
|

Re: 1.58.1 bugfix release necessary?

beet-2
In reply to this post by Robert Ramey
Hi there,

> Am 26.04.2015 um 15:38 schrieb Robert Ramey <[hidden email]>:
>
> 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-tp4674686p4674817.html
> Sent from the Boost - Dev mailing list archive at Nabble.com.
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: 1.58.1 bugfix release necessary?

Robert Ramey
beet-2 wrote
Hi there,

> Am 26.04.2015 um 15:38 schrieb Robert Ramey <[hidden email]>:
>
> 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
Reply | Threaded
Open this post in threaded view
|

Re: 1.58.1 bugfix release necessary?

Klaim - Joël Lamotte
In reply to this post by Robert Ramey
On Sun, Apr 26, 2015 at 7:58 PM, Robert Ramey <[hidden email]> 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-tp4674686p4674826.html
> Sent from the Boost - Dev mailing list archive at Nabble.com.
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: 1.58.1 bugfix release necessary?

Michael Caisse-3
In reply to this post by Robert Ramey
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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: 1.58.1 bugfix release necessary?

Tim Blechmann-2
In reply to this post by 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.
>
> 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.



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