Support for BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION

newer
[config] Patch for clang.hpp to...

Joaquin M Lopez Munoz

8 Oct 2013 8 Oct '13

10:39 p.m.

I understand there's been some discussion about dropping support for compliers with BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION defined. Has some final decision been made about this? Thank you, Joaquín M López Muñoz Telefónica Digital

Show replies by date

Daniel James

8 Oct 8 Oct

10:51 p.m.

On 8 October 2013 23:39, Joaquin M Lopez Munoz wrote:

...

I understand there's been some discussion about dropping support for compliers with BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION defined. Has some final decision been made about this?

No, not yet. This is part of the "removals that we're considering" in the release notes.

Stephen Kelly

9 Oct 9 Oct

5:53 a.m.

On 10/09/2013 12:39 AM, Joaquin M Lopez Munoz wrote:

...

I understand there's been some discussion about dropping support for compliers with BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION defined. Has some final decision been made about this?

What is the question behind the question? Thanks, Steve.

Joaquin M Lopez Munoz

10 Oct 10 Oct

5:48 a.m.

New subject: [boost] Support for BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION

Stephen Kelly writes:

...

On 10/09/2013 12:39 AM, Joaquin M Lopez Munoz wrote:

...
I understand there's been some discussion about dropping support for compliers with BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION defined. Has some final decision been made about this?

What is the question behind the question?

Once the decision is taken, I can get rid of some workarounds in the Boost libs I maintain. Joaquín M López Muñoz Telefónica Digital

Stephen Kelly

8:21 a.m.

On 10/10/2013 07:48 AM, Joaquin M Lopez Munoz wrote:

...

Stephen Kelly writes:

...
...
I understand there's been some discussion about dropping support for compliers with BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION defined. Has some final decision been made about this? What is the question behind the question? Once the decision is taken, I can get rid of some workarounds in the Boost

On 10/09/2013 12:39 AM, Joaquin M Lopez Munoz wrote: libs I maintain.

Indeed. I already have patches ready to push which remove the use of the macro throughout boost. Thanks, Steve.

Joaquin M Lopez Munoz

10:57 a.m.

New subject: [boost] Support for BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION

Stephen Kelly writes:

...

On 10/10/2013 07:48 AM, Joaquin M Lopez Munoz wrote:

...
Stephen Kelly writes:

...
...
I understand there's been some discussion about dropping support for compliers with BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION defined. Has some final decision been made about this? What is the question behind the question? Once the decision is taken, I can get rid of some workarounds in the Boost

On 10/09/2013 12:39 AM, Joaquin M Lopez Munoz wrote: libs I maintain.

Indeed. I already have patches ready to push which remove the use of the macro throughout boost.

In my case, it's not so much about removing #ifdefs as about eliminating workarounds like this: Instead of template<typename T> foo{...}; template<typename T> foo{...}; I'm forced to write template<typename T> foo_type1{...}; template<typename T> foo_type2{...}; template struct foo: mpl::if_< is_same>, foo_type1<T>, foo_type2<T>

...

{}; These workarounds cannot be eliminated by simple grepping/deleting. Joaquín M López Muñoz Telefónica Digital

Stephen Kelly

11:12 a.m.

On 10/10/2013 12:57 PM, Joaquin M Lopez Munoz wrote:

...

Stephen Kelly writes:

...
On 10/10/2013 07:48 AM, Joaquin M Lopez Munoz wrote:

...
Stephen Kelly writes:

...
...
I understand there's been some discussion about dropping support for compliers with BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION defined. Has some final decision been made about this? What is the question behind the question? Once the decision is taken, I can get rid of some workarounds in the Boost

On 10/09/2013 12:39 AM, Joaquin M Lopez Munoz wrote: libs I maintain. Indeed. I already have patches ready to push which remove the use of the macro throughout boost. In my case, it's not so much about removing #ifdefs as about eliminating workarounds like this:

Instead of

template<typename T> foo{...}; template<typename T> foo{...};

I'm forced to write

template<typename T> foo_type1{...}; template<typename T> foo_type2{...};

template struct foo: mpl::if_< is_same>, foo_type1<T>, foo_type2<T>

...
{};

These workarounds cannot be eliminated by simple grepping/deleting.

Great example. This is exactly the kind of stuff I hoped could be removed by bumping compiler requirements. I've seen other similar stuff too. Thanks, Steve.

Robert Ramey

6:02 p.m.

Joaquin M Lopez Munoz wrote:

...

Stephen Kelly writes:

...
On 10/10/2013 07:48 AM, Joaquin M Lopez Munoz wrote:

...
Stephen Kelly writes:

...
...
I understand there's been some discussion about dropping support for compliers with BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION defined. Has some final decision been made about this? What is the question behind the question? Once the decision is taken, I can get rid of some workarounds in

On 10/09/2013 12:39 AM, Joaquin M Lopez Munoz wrote: the Boost libs I maintain.

Indeed. I already have patches ready to push which remove the use of the macro throughout boost.

In my case, it's not so much about removing #ifdefs as about eliminating workarounds like this:

Instead of

template<typename T> foo{...}; template<typename T> foo{...};

I'm forced to write

template<typename T> foo_type1{...}; template<typename T> foo_type2{...};

template struct foo: mpl::if_< is_same>, foo_type1<T>, foo_type2<T>

...
{};

Why are you forced to write this? You are not forced to write code compatible with older compilers. It's only an option. Just write the code you want and note that your library is not compatible with certain "older" compilers. Combatibility with non-standard C++ has never been a boost requirement and this is explicitly stated somewhere on the boost website. Robert Ramey

Joaquin M Lopez Munoz

6:39 p.m.

New subject: [boost] Support for BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION

Robert Ramey writes:

...

Joaquin M Lopez Munoz wrote:

...
Stephen Kelly writes:

...
On 10/10/2013 07:48 AM, Joaquin M Lopez Munoz wrote:

...
Stephen Kelly writes:

...
On 10/09/2013 12:39 AM, Joaquin M Lopez Munoz wrote:

...
I understand there's been some discussion about dropping support for compliers with BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION defined. Has some final decision been made about this?

[...] In my case, it's not so much about removing #ifdefs as about eliminating workarounds like this:

Instead of

[...]

I'm forced to write

[...]

Why are you forced to write this? You are not forced to write code compatible with older compilers. It's only an option. Just write the code you want and note that your library is not compatible with certain "older" compilers. Combatibility with non-standard C++ has never been a boost requirement and this is explicitly stated somewhere on the boost website.

I didn't express myself clearly. Of course noone forces me to write for non-compliant compilers, but when I began Boost.MultiIndex non-compliance was the norem (remember the days of MSC++ 6.0) and I carefully wrote all the necessary workadounds, up to a certain point (never could make the lib work for Borland commpilers.) Now that the situation with compilers is much better, I'm happy to drop legacy support: I just prefer to do it in alignment with official Boost policies about which compilers are defintely abandoned. Joaquín M López Muñoz Telefónica Digital

Robert Ramey

8:28 p.m.

Joaquin M Lopez Munoz wrote:

...

Robert Ramey writes:

...
Joaquin M Lopez Munoz wrote:

...
Stephen Kelly writes:

...
On 10/10/2013 07:48 AM, Joaquin M Lopez Munoz wrote:

...
Stephen Kelly writes:

...
On 10/09/2013 12:39 AM, Joaquin M Lopez Munoz wrote: > I understand there's been some discussion about dropping support > for compliers with BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION > defined. Has some final decision been made about this?

[...] In my case, it's not so much about removing #ifdefs as about eliminating workarounds like this:

Instead of

[...]

I'm forced to write

[...]

Why are you forced to write this? You are not forced to write code compatible with older compilers. It's only an option. Just write the code you want and note that your library is not compatible with certain "older" compilers. Combatibility with non-standard C++ has never been a boost requirement and this is explicitly stated somewhere on the boost website.

I didn't express myself clearly. Of course noone forces me to write for non-compliant compilers, but when I began Boost.MultiIndex non-compliance was the norem (remember the days of MSC++ 6.0) and I carefully wrote all the necessary workadounds, up to a certain point (never could make the lib work for Borland commpilers.) Now that the situation with compilers is much better, I'm happy to drop legacy support: I just prefer to do it in alignment with official Boost policies about which compilers are defintely abandoned.

But you wouldn't want to go back and make adjustments in the current code just to make it non-functional with older compilers, would you? What is the return on THAT investment. Wouldn't it be best to just ignore these macros going forward? RObert Ramey

...

Joaquín M López Muñoz Telefónica Digital

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

Joaquin M Lopez Munoz

9:52 p.m.

New subject: [boost] Support for BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION

Robert Ramey writes:

...

Joaquin M Lopez Munoz wrote:

...
I didn't express myself clearly. Of course noone forces me to write for non-compliant compilers, but when I began Boost.MultiIndex non-compliance was the norem (remember the days of MSC++ 6.0) and I carefully wrote all the necessary workadounds, up to a certain point (never could make the lib work for Borland commpilers.) Now that the situation with compilers is much better, I'm happy to drop legacy support: I just prefer to do it in alignment with official Boost policies about which compilers are defintely abandoned.

But you wouldn't want to go back and make adjustments in the current code just to make it non-functional with older compilers, would you? What is the return on THAT investment.

Cleaner, more readable code (hey, I won't be around forever :-) let's make life easier for maintainers to come.) When deleting non-macro-based contortions such as the one I described before, we get also potentially faster compile times. Joaquín M López Muñoz Telefónica Digital

Stephen Kelly

12 Oct 12 Oct

1:16 p.m.

On 10/10/2013 11:52 PM, Joaquin M Lopez Munoz wrote:

...

...
...
But you wouldn't want to go back and make adjustments in the current code just to make it non-functional with older compilers, would you? What is the return on THAT investment. Cleaner, more readable code (hey, I won't be around forever :-)

Exactly. Robert, we've been around this roundabout before. Please don't take us around it again. http://thread.gmane.org/gmane.comp.lib.boost.devel/244216/focus=244218 * Making the code look more like normal c++ (eg revisions 85957 and 85958), which makes reading/contributing easier. It is easier to reason about modern code than code which is designed to accomodate obsolete workarounds. Thanks, Steve.

Daniel James

13 Oct 13 Oct

12:21 p.m.

On 12 October 2013 14:16, Stephen Kelly wrote:

...

On 10/10/2013 11:52 PM, Joaquin M Lopez Munoz wrote:

...
...
...
But you wouldn't want to go back and make adjustments in the current code just to make it non-functional with older compilers, would you? What is the return on THAT investment. Cleaner, more readable code (hey, I won't be around forever :-)

Exactly.

Robert, we've been around this roundabout before. Please don't take us around it again.

http://thread.gmane.org/gmane.comp.lib.boost.devel/244216/focus=244218

Did you mean to link to that thread? Because I think Peter's point was valid. Cleaner code is nice, but if it risks breaking something, it's more trouble than it's worth. Since much of boost is only lightly maintained, or not maintained at all, stability is the way we avoid breaking things.

Stephen Kelly

6:31 p.m.

On 10/13/2013 02:21 PM, Daniel James wrote:

...

On 12 October 2013 14:16, Stephen Kelly wrote:

...
On 10/10/2013 11:52 PM, Joaquin M Lopez Munoz wrote:

...
...
...
But you wouldn't want to go back and make adjustments in the current code just to make it non-functional with older compilers, would you? What is the return on THAT investment. Cleaner, more readable code (hey, I won't be around forever :-) Exactly.

Robert, we've been around this roundabout before. Please don't take us around it again.

http://thread.gmane.org/gmane.comp.lib.boost.devel/244216/focus=244218 Did you mean to link to that thread? Because I think Peter's point was valid.

Peter? Don't you mean Robert?

...

Cleaner code is nice, but if it risks breaking something, it's more trouble than it's worth. Since much of boost is only lightly maintained, or not maintained at all, stability is the way we avoid breaking things.

The change under discussion seems to be to a library which is maintained. By Joaquin. My changes amount to removal of dead code (once the macro I'm processing is no-longer defined). That doesn't require knowledge of the library in question, but just basic knowledge of how the preprocessor works. That's very basic. I've made some typos, and I'm glad of more reviews. Thanks, Steve.

Daniel James

14 Oct 14 Oct

10:57 a.m.

On 13 October 2013 19:31, Stephen Kelly wrote:

...

On 10/13/2013 02:21 PM, Daniel James wrote:

...
On 12 October 2013 14:16, Stephen Kelly wrote:

...
On 10/10/2013 11:52 PM, Joaquin M Lopez Munoz wrote:

...
...
...
But you wouldn't want to go back and make adjustments in the current code just to make it non-functional with older compilers, would you? What is the return on THAT investment. Cleaner, more readable code (hey, I won't be around forever :-) Exactly.

Robert, we've been around this roundabout before. Please don't take us around it again.

http://thread.gmane.org/gmane.comp.lib.boost.devel/244216/focus=244218 Did you mean to link to that thread? Because I think Peter's point was valid.

Peter? Don't you mean Robert?

You linked to a discussion with Peter Dimov.

...

...
Cleaner code is nice, but if it risks breaking something, it's more trouble than it's worth. Since much of boost is only lightly maintained, or not maintained at all, stability is the way we avoid breaking things.

The change under discussion seems to be to a library which is maintained. By Joaquin.

You have made other changes.

...

My changes amount to removal of dead code (once the macro I'm processing is no-longer defined). That doesn't require knowledge of the library in question, but just basic knowledge of how the preprocessor works. That's very basic. I've made some typos, and I'm glad of more reviews.

Well not quite, sometimes there are subtle issues involved, such as the one Peter mentioned about compilers that pretend to be Visual C++. The problem is that a lot of these changes aren't getting reviewed. Most of the responses have been about things which cause compile failures on recent compilers. That isn't going to catch everything.

Stephen Kelly

11:03 a.m.

On 10/14/2013 12:57 PM, Daniel James wrote:

...

Most of the responses have been about things which cause compile failures on recent compilers. That isn't going to catch everything.

The reported problems regarded typos resulting in preprocessing failure, not compile failure. Thanks, Steve.

Sergey Cheban

10 Oct 10 Oct

11:09 a.m.

On 10.10.2013 12:21, Stephen Kelly wrote:

...

...
...
...
I understand there's been some discussion about dropping support for compliers with BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION defined. Has some final decision been made about this? What is the question behind the question? Once the decision is taken, I can get rid of some workarounds in the Boost libs I maintain.

Indeed. I already have patches ready to push which remove the use of the macro throughout boost. I think it is reasonable to push them in several days after releasing 1.55 (providing there is no significant negative feedback).

-- Sergey Cheban

Stephen Kelly

11:14 a.m.

On 10/10/2013 01:09 PM, Sergey Cheban wrote:

...

On 10.10.2013 12:21, Stephen Kelly wrote:

...
...
...
...
I understand there's been some discussion about dropping support for compliers with BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION defined. Has some final decision been made about this? What is the question behind the question? Once the decision is taken, I can get rid of some workarounds in the Boost libs I maintain.

Indeed. I already have patches ready to push which remove the use of the macro throughout boost. I think it is reasonable to push them in several days after releasing 1.55 (providing there is no significant negative feedback).

That makes no sense at all. My patches affect the master branch, not the release branch. I'd prefer to commit them in a few days from now. There's a lot more to do and waiting until November is unnecessary. Thanks, Steve.

Sergey Cheban

1 p.m.

...

...
I think it is reasonable to push them in several days after releasing 1.55 (providing there is no significant negative feedback). That makes no sense at all. My patches affect the master branch, not the release branch. The current gap between the trunk and release branches looks strange for me. I've read several times about changesets that were living on the

On 10.10.2013 15:14, Stephen Kelly wrote: trunk for a long time without being merged to the release. I think that this practice is bad and the changesets on the trunk should be merged to the release branch ASAP providing the tests are green. PS. If we've already been using git, you could commit your changeset to your local repository. -- Sergey Cheban

Stephen Kelly

1:08 p.m.

On 10/10/2013 03:00 PM, Sergey Cheban wrote:

...

On 10.10.2013 15:14, Stephen Kelly wrote:

...
...
I think it is reasonable to push them in several days after releasing 1.55 (providing there is no significant negative feedback). That makes no sense at all. My patches affect the master branch, not the release branch. The current gap between the trunk and release branches looks strange for me. I've read several times about changesets that were living on the trunk for a long time without being merged to the release. I think that this practice is bad and the changesets on the trunk should be merged to the release branch ASAP providing the tests are green.

This is so shocking that I'm certain I've misunderstood you.

...

PS. If we've already been using git, you could commit your changeset to your local repository.

I'm using git-svn. The patches are written, committed, locally-tested and ready to push. Thanks, Steve.

Sergey Cheban

1:47 p.m.

On 10.10.2013 17:08, Stephen Kelly wrote:

...

...
...
...
I think it is reasonable to push them in several days after releasing 1.55 (providing there is no significant negative feedback). That makes no sense at all. My patches affect the master branch, not the release branch. The current gap between the trunk and release branches looks strange for me. I've read several times about changesets that were living on the trunk for a long time without being merged to the release. I think that this practice is bad and the changesets on the trunk should be merged to the release branch ASAP providing the tests are green. This is so shocking that I'm certain I've misunderstood you. May be I just don't understand the current boost workflow. But as I can see the current workflow leads to the problems like the following:

======================================== On 09.10.2013 3:12, Rich E wrote:

...

I'm seeing that Fusion has not been updated with fixes for #5010 https://svn.boost.org/trac/boost/ticket/5010#comment:24 a /3/ /year old(!)/ bug, that is reported as fixed. Why is this? From what I can tell, changeset #4441 https://svn.boost.org/trac/boost/changeset/84441 fixes the issues I ran into, but the 1.55beta package doesn't reflect this... ========================================

and following: ======================================== On 03.08.2013 1:33, Gennadiy Rozental wrote:

...

Tim Blechmann writes:

...
i've reported an issue before that boost.test in the release branch is pretty broken. *all* tests of the boost.heap testsuite segfault like this:

There were no changes in boost release for several years. Can you wor karound it for now?

...
boost.test in trunk works fine, though ... i wonder, will it eventually be merged to release?

I lost my work on new docs unfortunately to broken laptop, still trying to revive it, but I'm lacking time to really get to it. Maybe this can give me another reason to finally push it out. ========================================

and following: ======================================== On 08.10.2013 12:50, Akira Takahashi wrote:

...

2013/10/8 Domagoj Saric mailto:dsaritz@gmail.com> ... With MSVC12 RC: * 1.54 and 1.55 b1 RC - lots of: ..\boost/iterator/detail/__facade_iterator_category.hpp(__166) : error C2039: 'assert_not_arg' : is not a member of 'boost::mpl'

This issue fixed by this commit. http://lists.boost.org/boost-commit/2013/05/46330.php

However, not merge to release branch yet. ========================================

...

...
PS. If we've already been using git, you could commit your changeset to your local repository. I'm using git-svn. The patches are written, committed, locally-tested and ready to push.

-- Sergey Cheban

Stephen Kelly

4:43 p.m.

On 10/10/2013 03:47 PM, Sergey Cheban wrote:

...

On 10.10.2013 17:08, Stephen Kelly wrote:

...
...
...
...
I think it is reasonable to push them in several days after releasing 1.55 (providing there is no significant negative feedback). That makes no sense at all. My patches affect the master branch, not the release branch. The current gap between the trunk and release branches looks strange for me. I've read several times about changesets that were living on the trunk for a long time without being merged to the release. I think that this practice is bad and the changesets on the trunk should be merged to the release branch ASAP providing the tests are green. This is so shocking that I'm certain I've misunderstood you.

Well, apparently I did not misunderstand you. :) Color me shocked. What is the point of creating a release branch to stabilize, if you are just going to merge trunk back into it later? Especially for such very dubious reasoning as 'it looks strange to me'? Define strange.

...

May be I just don't understand the current boost workflow. But as I can see the current workflow leads to the problems like the following:

You're quoting things out of context instead of linking to gmane where there would be context. If you wish though, I can make guesses at what's going on.

...

======================================== On 09.10.2013 3:12, Rich E wrote:

...
I'm seeing that Fusion has not been updated with fixes for #5010 https://svn.boost.org/trac/boost/ticket/5010#comment:24 a /3/ /year old(!)/ bug, that is reported as fixed. Why is this? From what I can tell, changeset #4441 https://svn.boost.org/trac/boost/changeset/84441 fixes the issues I ran into, but the 1.55beta package doesn't reflect this... ========================================

What happened? Did someone commit the fix to trunk instead of release? If so, then maybe they made a mistake. If it was a mistake, then cherry-pick the commit. Done. No big deal. Mistakes happen.

...

and following:

...
Tim Blechmann writes:

...
i've reported an issue before that boost.test in the release branch is pretty broken. *all* tests of the boost.heap testsuite segfault

======================================== On 03.08.2013 1:33, Gennadiy Rozental wrote: like this:

...
There were no changes in boost release for several years.

It is my understanding that the release branch should contain the boost 1.5.5 beta. With that understanding in mind, I can't understand this quoted sentence. What does it mean?

...

...
it for now?

...
boost.test in trunk works fine, though ... i wonder, will it eventually be merged to release?

I lost my work on new docs unfortunately to broken laptop, still

Can you wor karound trying to

...
revive it, but I'm lacking time to really get to it. Maybe this can give me another reason to finally push it out. ========================================

Broken laptops are not related to trunk and release branches. I don't know why you quoted this.

...

and following: ======================================== On 08.10.2013 12:50, Akira Takahashi wrote:

...
2013/10/8 Domagoj Saric mailto:dsaritz@gmail.com> ... With MSVC12 RC: * 1.54 and 1.55 b1 RC - lots of: ..\boost/iterator/detail/__facade_iterator_category.hpp(__166) : error C2039: 'assert_not_arg' : is not a member of 'boost::mpl'

This issue fixed by this commit. http://lists.boost.org/boost-commit/2013/05/46330.php

However, not merge to release branch yet. ========================================

What's the problem? If someone writes that it is not merged *yet*, then they intend to apply it to the release branch somehow, right? Is merging trunk into release part of the boost release strategy? Thanks, Steve.

Jonathan Wakely

4:48 p.m.

On 10 October 2013 17:43, Stephen Kelly wrote:

...

...
...
There were no changes in boost release for several years.

It is my understanding that the release branch should contain the boost 1.5.5 beta. With that understanding in mind, I can't understand this quoted sentence. What does it mean?

I _assume_ it means no changes to the relevant part of Boost.Test in any recent releases. Just a guess though.

Sergey Cheban

11 Oct 11 Oct

5:59 a.m.

10.10.2013 20:43, Stephen Kelly пишет:

...

...
May be I just don't understand the current boost workflow. But as I can see the current workflow leads to the problems like the following:

You're quoting things out of context instead of linking to gmane where there would be context. Ok, here are the gmane links: http://article.gmane.org/gmane.comp.lib.boost.user/79812 http://article.gmane.org/gmane.comp.lib.boost.devel/243174 http://article.gmane.org/gmane.comp.lib.boost.user/79805

...

...
======================================== On 09.10.2013 3:12, Rich E wrote:

...
I'm seeing that Fusion has not been updated with fixes for #5010 https://svn.boost.org/trac/boost/ticket/5010#comment:24 a /3/ /year old(!)/ bug, that is reported as fixed. Why is this? From what I can tell, changeset #4441 https://svn.boost.org/trac/boost/changeset/84441 fixes the issues I ran into, but the 1.55beta package doesn't reflect this... ========================================

What happened? Did someone commit the fix to trunk instead of release? If so, then maybe they made a mistake. If it was a mistake, then cherry-pick the commit. Done. No big deal. Mistakes happen. As I've understood, someone has forgotten to commit the working changeset to the release branch.

...

...
...
Tim Blechmann writes:

...
i've reported an issue before that boost.test in the release branch is pretty broken. *all* tests of the boost.heap testsuite segfault

======================================== On 03.08.2013 1:33, Gennadiy Rozental wrote: like this:

...
There were no changes in boost release for several years.

It is my understanding that the release branch should contain the boost 1.5.5 beta. With that understanding in mind, I can't understand this quoted sentence. What does it mean? If I've understood correctly, someone else has forgotten to put the working version of the boost.test to the release branch.

...

...
and following: ======================================== On 08.10.2013 12:50, Akira Takahashi wrote:

...
2013/10/8 Domagoj Saric mailto:dsaritz@gmail.com> ... With MSVC12 RC: * 1.54 and 1.55 b1 RC - lots of: ..\boost/iterator/detail/__facade_iterator_category.hpp(__166) : error C2039: 'assert_not_arg' : is not a member of 'boost::mpl'

This issue fixed by this commit. http://lists.boost.org/boost-commit/2013/05/46330.php

However, not merge to release branch yet. ========================================

What's the problem? If someone writes that it is not merged *yet*, then they intend to apply it to the release branch somehow, right? The problem is that developers are forgetting to copy working changesets to the release branch. This changeset has been made on the trunk before 1.54 was released.

...

Is merging trunk into release part of the boost release strategy? Yes and no. The individual changes are initially made on the trunk and have to be merged to the release branch after cycling the tests (but sometimes developers are forgetting to merge them). The whole trunk is never being merged to the release branch.

-- Best regards, Sergey Cheban

4167

Age (days ago)

4173

Last active (days ago)

List overview

Download

23 comments

6 participants

participants (6)

Daniel James
Joaquin M Lopez Munoz
Jonathan Wakely
Robert Ramey
Sergey Cheban
Stephen Kelly