Support for BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION
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
On 8 October 2013 23:39, Joaquin M Lopez Munoz <joaquin@tid.es> 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.
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.
Stephen Kelly <steveire <at> gmail.com> 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
On 10/10/2013 07:48 AM, Joaquin M Lopez Munoz wrote:
Stephen Kelly <steveire <at> gmail.com> 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.
Indeed. I already have patches ready to push which remove the use of the macro throughout boost. Thanks, Steve.
Stephen Kelly <steveire <at> gmail.com> writes:
On 10/10/2013 07:48 AM, Joaquin M Lopez Munoz wrote:
Stephen Kelly <steveire <at> gmail.com> 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.
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<T,type1>{...}; template<typename T> foo<T,type2>{...}; I'm forced to write template<typename T> foo_type1{...}; template<typename T> foo_type2{...}; template<typename T,typename Q> struct foo: mpl::if_< is_same<Q,type1>>, 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
On 10/10/2013 12:57 PM, Joaquin M Lopez Munoz wrote:
Stephen Kelly <steveire <at> gmail.com> writes:
On 10/10/2013 07:48 AM, Joaquin M Lopez Munoz wrote:
Stephen Kelly <steveire <at> gmail.com> 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. 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<T,type1>{...}; template<typename T> foo<T,type2>{...};
I'm forced to write
template<typename T> foo_type1{...}; template<typename T> foo_type2{...};
template<typename T,typename Q> struct foo: mpl::if_< is_same<Q,type1>>, 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.
Joaquin M Lopez Munoz wrote:
Stephen Kelly <steveire <at> gmail.com> writes:
On 10/10/2013 07:48 AM, Joaquin M Lopez Munoz wrote:
Stephen Kelly <steveire <at> gmail.com> 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.
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<T,type1>{...}; template<typename T> foo<T,type2>{...};
I'm forced to write
template<typename T> foo_type1{...}; template<typename T> foo_type2{...};
template<typename T,typename Q> struct foo: mpl::if_< is_same<Q,type1>>, 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
Robert Ramey <ramey <at> rrsd.com> writes:
Joaquin M Lopez Munoz wrote:
Stephen Kelly <steveire <at> gmail.com> writes:
On 10/10/2013 07:48 AM, Joaquin M Lopez Munoz wrote:
Stephen Kelly <steveire <at> gmail.com> 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
Joaquin M Lopez Munoz wrote:
Robert Ramey <ramey <at> rrsd.com> writes:
Joaquin M Lopez Munoz wrote:
Stephen Kelly <steveire <at> gmail.com> writes:
On 10/10/2013 07:48 AM, Joaquin M Lopez Munoz wrote:
Stephen Kelly <steveire <at> gmail.com> 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
Robert Ramey <ramey <at> rrsd.com> 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
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.
On 12 October 2013 14:16, Stephen Kelly <steveire@gmail.com> 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.
On 10/13/2013 02:21 PM, Daniel James wrote:
On 12 October 2013 14:16, Stephen Kelly <steveire@gmail.com> 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.
On 13 October 2013 19:31, Stephen Kelly <steveire@gmail.com> wrote:
On 10/13/2013 02:21 PM, Daniel James wrote:
On 12 October 2013 14:16, Stephen Kelly <steveire@gmail.com> 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.
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.
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
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.
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.
PS. If we've already been using git, you could commit your changeset to your local repository. -- Sergey Cheban
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.
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 <tim <at> klingt.org> 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 <dsaritz@gmail.com <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
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:
======================================== On 03.08.2013 1:33, Gennadiy Rozental wrote:
Tim Blechmann <tim <at> klingt.org> 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.
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?
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. ========================================
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 <dsaritz@gmail.com <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.
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.
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.
======================================== On 03.08.2013 1:33, Gennadiy Rozental wrote:
Tim Blechmann <tim <at> klingt.org> 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.
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 <dsaritz@gmail.com <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
participants (6)
-
Daniel James -
Joaquin M Lopez Munoz -
Jonathan Wakely -
Robert Ramey -
Sergey Cheban -
Stephen Kelly