Beman Dawes wrote:

Matthias Troyer wrote:

...

On Jul 8, 2008, at 3:30 AM, Beman Dawes wrote:

...

Below is a list of libraries whose header files appear to differ between the trunk and branches/release.

...

mpi

Hi Beman,

I've done a diff on every single file and see no difference. Can you tell me which file is the problem?

It's a false alarm.

The script is looking at the file size, and assuming the contents are different if the size is different. For these files:

boost/mpi/detail/mpi_datatype_primitive.hpp different size boost/mpi/detail/packed_oprimitive.hpp different size

The size is different (and I've used several ways to look at the sizes) even though contents are the same.

I'll track down what is happening and fix the script to avoid the problem in the future.

Ha! Those two files differ at the binary level. The one in branches/release has lines terminated with 0x0d 0x0a, while the one in trunk is all 0x0a terminations. I suspect the same confusion would occur if a file with tabs was converted to no tabs. That's an odd situation. Should the script detect those situations and do the merge itself? --Beman

Gennaro Prota wrote:

Beman Dawes wrote:

...

...

It's a false alarm.

The script is looking at the file size, and assuming the contents are different if the size is different. For these files:

boost/mpi/detail/mpi_datatype_primitive.hpp different size boost/mpi/detail/packed_oprimitive.hpp different size

The size is different (and I've used several ways to look at the sizes) even though contents are the same.

I'll track down what is happening and fix the script to avoid the problem in the future.

Ha! Those two files differ at the binary level. The one in branches/release has lines terminated with 0x0d 0x0a, while the one in trunk is all 0x0a terminations.

Scratching my head... doesn't the script work on *checked-out* copies? Because in that case svn:eol-style (set to native)...

That's a good question! As an experiment, I deleted the file from both my working copies, then updated the directories to get fresh copies. This time both are the same length, and both use CR/LF line terminations. That's as expected given the machine runs Windows. I'll do a fresh checkout of my trunk working copy. It is an old one that may have checked out some files before our svn:eol-style processing was finalized. Thanks for bringing this up! --Beman

David Abrahams wrote:

Why not just svn diff the repository paths and avoid any vagaries about your local line endings?

Hum... Should work. I had tried svn merge --dry-run, but that doesn't really work. Later... Yes, svn diff on repository paths works fine. Very slow, but that doesn't really matter since this analysis only has to be done a few times per release cycle. Thanks, --Beman

Emil Dotchevski wrote:

The differences in the exception library were very minor but I merged them in anyway. Also, I updated the documentation.

Thanks, --Beman

Chris Newbold wrote:

...

From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Beman Dawes Sent: Monday, July 07, 2008 9:30 PM

...

Below is a list of libraries whose header files appear to differ between the trunk and branches/release.

...

pool

The differences here are benign and can be merged to branches/release or are line-ending issues.

Please go ahead and do the merge. Thanks, --Beman

Andreas Huber wrote:

Hi Beman

...

statechart

Some code maintenance + doc changes, test run fine on trunk but one example is broken on many platforms. Is it ok to merge this weekend, provided that example is fixed previously?

Yes. Thanks, --Beman

----- Original Message ----- From: "James Sharpe" <james.sharpe@gmail.com> To: <boost@lists.boost.org> Sent: Friday, July 11, 2008 11:20 AM Subject: Re: [boost] [1.36.0] Libraries with unmerged changes?

Beman,

I'm calling into question the decisions you've made with regards to where you start a new branch for a release from in the light of the fact that you are diffing against trunk. To me it seems like you are making a lot of work for yourself and maintainers by requiring that changes get merged from trunk to release, with release having been based upon the previous release. If you're only then going to diff against trunk for differences then why not just start from trunk in the first place and revert commits that are destined for the next release? Seems to me like you'd have a much easier job and people wouldn't need to worry so much about merging before the deadline; all they'd have to ensure is that there changes are in trunk before the release branch creation date and then it would simply be a case of reverting features that aren't destined for the release. I think this would be a smaller workload for creating releases, as then the remainder of the time can be spent patching the release to remove regressions.

What are people's thoughts on the matter?

Hello, I thought this was already the case. To me this is the natural way. Developements that do not pretend to be included in the next release should be done on a separate branch or on the sandbox. Once a release branch is created, the trunk should be free for new libraries, and new developements for the next release. In this way the delay of a release is 6 months, but a new release is delivered every three months. This avoid to have libraries that use something from the truck that will not be merged on the release branch. Of course the modification done on the release branch must be merged on the trunk. What is the interest to have two branches trunk and release if its contents must be synchronized? Best Vicente Juan Botet Escriba

2008/7/11 David Abrahams <dave@boostpro.com>:

Yes, that is "standard practice." But standard practice for projects that care about stability is also that failures are not allowed to persist on the trunk.

This isn't necessarily the case; take the linux kernel for example which does care about stability, but the workflow they currently use ensures stability when it comes to release time, but in between during the 'merge window' instability is allowed. Speaking only for myself here, it seems like we can't get people to

operate that way; a really stable trunk, and development on branches just don't seem to be in our culture as a group. That's why I think we're maintaining a separate stable release branch.

I think that the reason development on branches isn't in the groups culture is because boost is actually a number of projects all under one umbrella title 'boost'. This means that there is little code contention because there is a high degree of code ownership; I get the impression that people generally don't hack on others code that much, apart from the odd bug fix. The other reason branches tend not to get used is that you don't get testing on other platforms. I am frankly not sure why Beman is inspecting the differences; it was my

presumption that we could do development in trunk without worrying about it, because the release branch is explicitly separated.

Indeed, I understand that he is making sure that developers have merged changes they intended to merge; as I know a number of them missed the official merge cutoff date, but again learning from the kernel release process, the equivalent 'merge window' caught out some developers initially but they were strict about it; I think that boost should take a similar stance since the developers learnt that they had to get their changes in during the window or wait for the next release, and once the momentum of releases picked up this was less of an issue. It also has helped with maintaining stability; since developers will tend to concentrate on working towards a particular release; if you know your changes are going to take slightly longer to develop then you target the next release, and by using DVCS this is easily done and doesn't ever create any confusion as the developer maintains his/her branch until its ready for integration upon which point a integration request is made and either further, wider testing occurs or it gets merged into the next release. James

- Original message - [SNIP]What's the obsession over a DVCS? I personally find that the workflow of a DVCS is better suited to frequent merges and frequent commits. Personally I find tools such as gitk useful in visualizing the progress of the project, and I just in general feel much more comfortable with merging with a DVCS tool than with subversion. I get the feeling that most people working on boost haven't actually tried a DVCS, and I would encourage people to try it out if they haven't already. James Sent from Google Mail for mobile On 7/12/08, Daryle Walker <darylew@hotmail.com> wrote:

On Jul 11, 2008, at 12:57 PM, James Sharpe wrote:

...

2008/7/11 David Abrahams <dave@boostpro.com>: [SNIP]

...

I am frankly not sure why Beman is inspecting the differences; it was my

...

presumption that we could do development in trunk without worrying about it, because the release branch is explicitly separated.

Indeed, I understand that he is making sure that developers have merged changes they intended to merge; as I know a number of them missed the official merge cutoff date, but again learning from the kernel release process, the equivalent 'merge window' caught out some developers initially but they were strict about it; I think that boost should take a similar stance since the developers learnt that they had to get their changes in during the window or wait for the next release, and once the momentum of releases picked up this was less of an issue. It also has helped with maintaining stability; since developers will tend to concentrate on working towards a particular release; if you know your changes are going to take slightly longer to develop then you target the next release, and by using DVCS this is easily done and doesn't ever create any confusion as the developer maintains his/her branch until its ready for integration upon which point a integration request is made and either further, wider testing occurs or it gets merged into the next release.

What's the obsession over a DVCS? Wouldn't any VCS that supports branching (and merging), like our current Subversion, be sufficient?

-- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

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

-- Sent from Google Mail for mobile | mobile.google.com

David Abrahams wrote:

I am frankly not sure why Beman is inspecting the differences; it was my presumption that we could do development in trunk without worrying about it, because the release branch is explicitly separated.

Because it is clear in looking at release test failures that a lot of changes and fixes that have been made to trunk have not been merged into release, yet many libraries are depending on changes and fixes in other libraries getting merged. --Beman

James Sharpe wrote:

Beman,

I'm calling into question the decisions you've made with regards to where you start a new branch for a release from in the light of the fact that you are diffing against trunk. To me it seems like you are making a lot of work for yourself and maintainers by requiring that changes get merged from trunk to release, with release having been based upon the previous release. If you're only then going to diff against trunk for differences then why not just start from trunk in the first place and revert commits that are destined for the next release? Seems to me like you'd have a much easier job and people wouldn't need to worry so much about merging before the deadline; all they'd have to ensure is that there changes are in trunk before the release branch creation date and then it would simply be a case of reverting features that aren't destined for the release. I think this would be a smaller workload for creating releases, as then the remainder of the time can be spent patching the release to remove regressions.

What are people's thoughts on the matter?

These weren't my personal decisions. They were discussed at length over a long period of time to try to overcome the problems of the approach used prior to 1.35.0. I doubt you will find much support for going back to the old "wild west" trunk and then branch approach. It just didn't work for Boost. --Beman

Emil Dotchevski wrote:

On Mon, Jul 14, 2008 at 3:33 PM, Beman Dawes <bdawes@acm.org> wrote:

...

These weren't my personal decisions. They were discussed at length over a long period of time to try to overcome the problems of the approach used prior to 1.35.0. I doubt you will find much support for going back to the old "wild west" trunk and then branch approach. It just didn't work for Boost.

I did not participate in the previous discussion and I'm sure there are good reasons behind the current system, but it can be argued that the new approach doesn't work very well either.

From my standpoint, it is working a lot better than the old system. While the release process may seem chaotic at the moment, this is only the second time we have used the new approach and it is already much smoother than with the first release using the new approach. It looks like we are actually going to get a release out fairly close to when it was scheduled to go out! The release team is still making improvements as we go along, too, and that should help with future releases. The time we took last release to make many reliability, reporting, snapshot, and other changes is already paying big dividends. This time we should come out of the release with better release management documentation, still more QA tools, and better scheduling. --Beman

On Tue, Jul 15, 2008 at 10:12 AM, Robert Ramey <ramey@rrsd.com> wrote:

Proposal:All tests for a particular library should be run against the latest or next release.

This can't work if a library depends on a another library that was changed. You'd be testing against the old version of that library, which isn't very helpful (meaning, your code may be out of date and you might not know about major problems until much later.) Your proposed approach would work if we elect to freeze the interface and the semantics of some libraries. Then you can (actually, should) test against any/all versions (which isn't unlike using STL.)

b) Changes on the trunk affect other libraries. Currently we have a situation where a change in config breaks a serialization jam fie. OK so we fix the jamfile in the trunk. Now we merge into the release. Uh-breaks again since the config changes aren't merged into the release. OK we'll roll it back. Now the config changes are merged into the release. Damn, breaks again. OK merge the jamfile changes from trunk - again. Obviously this is a huge waste of time.

This is the effect of coupling. For example, the Exception library depends on intrusive_ptr. The only way to make it not depend on intrusive_ptr is to not use it (duh.) Same with Boost Config: having a single configuration point is convenient but the price of that convenience is coupling. This is actually a good argument for branching the release branch off of some version of trunk. Presumably, the tests on trunk reflect the state of Boost in its entirety, dependencies and all. I think that I understand the reasoning behind the separate release branch. I think that it would work better if we had less coupling in Boost (I'm not sure if that's possible/practical, though.) Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

On Tue, Jul 15, 2008 at 12:40 PM, Robert Ramey <ramey@rrsd.com> wrote:

Emil Dotchevski wrote:

...

On Tue, Jul 15, 2008 at 10:12 AM, Robert Ramey <ramey@rrsd.com> wrote:

...

Proposal:All tests for a particular library should be run against the latest or next release.

This can't work if a library depends on a another library that was changed. You'd be testing against the old version of that library, which isn't very helpful (meaning, your code may be out of date and you might not know about major problems until much later.)

...

Your proposed approach would work if we elect to freeze the interface and the semantics of some libraries.

EXACTLY !!!

The whole concept of a library is that it has established interface and semantics that users of the library can depend upon. Without this, libraries are useless. One can't write code based on libraries whose interface and/or semantics are changing without notice.

If that was true, nobody would be using Boost. :) It's a fact, Boost libraries evolve and interfaces and implementations change all the time. You can argue that the changes are minor, but as you know they're significant enough to break tests in other libraries. For your proposal to work, we need a formal freeze for individual libraries. Without this, all bets are off, as far as I'm concerned.

...

This is the effect of coupling.

EXACTLY !!!

...

For example, the Exception library depends on intrusive_ptr. The only way to make it not depend on intrusive_ptr is to not use it (duh.)

Nope - The exception library should depend upon the intrusive_ptr library interface and semantics which should never change.(duh.)

I am on the fence actually. It was a difficult decision for me, to depend on intrusive_ptr. Ideally it wouldn't change but the reality is that it might. And if Boost Exception wouldn't benefit from a future improvement in intrusive_ptr, it's perhaps better not to depend on it, given how simple it is to "reinvent the wheel" in this particular case. We have plenty of examples for Boost libraries changing for the better. Boost Function changed between 1.35 and 1.36, both in terms of its interface and semantics. The new allocator support is better but we know it is a breaking change. Another example, shared_ptr now supports aliasing, which means that other Boost libraries that use aliasing can't be tested against 1.35. Had boost::function and boost::shared_ptr been frozen, we wouldn't have been able to make these improvements. If I have to pick between the improvements and the benefits of freezing these two Boost libraries in particular, I choose the improvements (with all the consequences, including release and testing difficulties.)

...

Same with Boost Config: having a single configuration point is convenient but the price of that convenience is coupling.

That is a very high a price to pay and should only be paid in extraordinary circumstances. In this particular case, the change should have been incorporated in the "next release" then it would have been detected when the "next release" is tested. At that point concensus would be built for either backing out the change, or rippling through the interface change to all libraries which depend upon it. During this period - and only during this period - the "next release" would be unstable and not a candidate for a release package.

Yes, but you are assuming that since the period of unstableness is limited in time, it's also limited in scope. For your approach to be practical, we need more formal classification of changes, I think.

...

I think that it would work better if we had less coupling in Boost (I'm not sure if that's possible/practical, though.)

LOL - Boost and other libaries are successful in inverse proportion to the coupling to other libraries.

Boost is not a library, it's a collection of libraries. I'm talking about dependencies between Boost libraries, not about Boost depending on external libraries (à propos, one of the arguments against using Boost is that it's very difficult to use this or that Boost library without introducing a defacto dependency on all of Boost.)

Suppose STL changed with every release - would it not be effectively useless?

No, but I agree that it would be a lot less useful. Also, the price of the stable STL is that we have to live with its problems. A good example is the broken allocator semantics of STL containers.

Obviously there will be rare occasions when interface and/or sematics of a library change (auto_pointer) when things like design errors are discovered. But these situations should occur only vary rarely.

The question is what to do when such changes in Boost libraries occur, because the reality is that (very often) they do. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

On Tue, Jul 15, 2008 at 2:50 PM, Robert Ramey <ramey@rrsd.com> wrote:

...

Boost Function changed between 1.35 and 1.36, both in terms of its interface and semantics. The new allocator support is better but we know it is a breaking change.

If this indeed occurred, it was an error on the part of the author and he's just told users - "you're all working for me now". Not a smart move if he wants to see his library widely used.

You have to strike a balance between breaking user code and improving the interface of a library. This is particularly important for interface changes that enable better implementations. In the case of boost::function, we guessed that the change is unlikely to affect many people. Nevertheless, you are right -- it's unfortunate that the affected users have to make changes in their code, but it would be even less fortunate to be stuck with the old interface, IMO.

...

Another example, shared_ptr now supports aliasing, which means that other Boost libraries that use aliasing can't be tested against 1.35.

aaaaa - other boost libraries which used alias before it was implemented in shared_ptr. That would be quite a trick.

No -- other Boost libraries which use aliasing before it was *released*. Boost Exception is an example of such a library: it does not compile against 1.35, precisely for this reason.

...

Had boost::function and boost::shared_ptr been frozen, we wouldn't have been able to make these improvements. If I have to pick between the improvements and the benefits of freezing these two Boost libraries in particular, I choose the improvements (with all the consequences, including release and testing difficulties.)

oh - don't forget about the difficulties of your current users who now have to adjust their apps to accomodate a new library interface.

This is an error. If you want new semantics/interface - give them new names and leave the old one's in.

That's not always preferable.

...

For your approach to be practical, we need more formal classification of changes, I think.

We only need two classificaitons: Either a change breaks interface/sematics or it doesn't. Every change fits into one of these two clasifications.

Alright, so we have two classifications. But if the classifications are not formal, you have the current situation, which is that libraries change -- not without a notice, but often that notice is limited to a SVN commit comment. It is unsafe to assume that such changes don't break interfaces or semantics. I've already given two examples; another example is boost::filesystem, whose interface changed too (both in terms of interface and semantics); also boost::thread changed recently. You're arguing that we mustn't be making breaking changes, and I'm saying that sometimes we do make breaking changes. These changes haven't made Boost less useful for me, on the contrary -- I welcome the improvements. We need a system that can deal with this reality. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

On Tue, Jul 15, 2008 at 4:13 PM, Robert Ramey <ramey@rrsd.com> wrote:

My proposal would:

a) save a lot of wasted time looking for problems which in fact are side effects of some un-anounced breaking changes.

b) make better use of boost test resources by running tests in a controlled manner rather than testing on a moving platform.

c) Improve boost by discouraging breaking changes.

d) Improve boost by usually having ready the "next release" thereby short circuiting calls for "point releases, etc"

Quoting your proposal: ---- "Proposal:All tests for a particular library should be run against the latest or next release." "Proposal:Libraries which have been tested against the latest or next release are merged into the release one at time and tests are run on the "next release". Failures here indicate interface breaking changes which would either be rolled back or addressed in each dependent library." ---- Let's consider the serialization library. If I understand your proposal correctly, it would be tested against the last and the next Boost release, but not in the trunk jungle. The aim of this testing is to prove that, if the test with the previous Boost release succeeds but the test with the next Boost release fails, a library that the serialization library depends on has introduced a breaking change which has to be fixed. However, the quoted proposal does not at all discourage breaking changes; it only detects them (and in fact it postpones the detection.) My suggestion was to formally flag certain libraries as frozen. The exact semantics of the "frozen" flag could be that any breaking change is a bug. This does discourage breaking changes (in those libs), and as far as I can tell achieves your goals, except that: A) breaking changes are detected as soon as they occur, and B) it allows for breaking changes in non-frozen libs to be treated as features and not bugs. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

Emil Dotchevski wrote:

"Proposal:All tests for a particular library should be run against the latest or next release."

"Proposal:Libraries which have been tested against the latest or next release are merged into the release one at time and tests are run on the "next release". Failures here indicate interface breaking changes which would either be rolled back or addressed in each dependent library." ----

Let's consider the serialization library.

If I understand your proposal correctly, it would be tested against the last and the next Boost release, but not in the trunk jungle.

Currently I run the serialization tests against the latest boost releases. I do this on my own machine. Any failures must then be due to recent changes, added features, etc. I do this even before checking in.

The aim of this testing is to prove that, if the test with the previous Boost release succeeds

Then I haven't broken my library.

but the test with the next Boost release fails, a library that the serialization library depends on has introduced a breaking change which has to be fixed.

Correct.

However, the quoted proposal does not at all discourage breaking changes; it only detects them

OK I would hope that this would discourage breaking changes. (and in fact it postpones the detection.) Here is where we differ. Now when someone checks in a breaking change. errors pop up all over the place in test results that the author who caused the problem doesn't have any reason to check. He who has had his library broken has to investigate the cause of the sudden breakage and trace down to its source and then complain. This is a huge pain in the neck and costs a lot of time and frustration.

My suggestion was to formally flag certain libraries as frozen. The exact semantics of the "frozen" flag could be that any breaking change is a bug.

LOL - that's my view exactly. The only difference is that I think all libraries should be considerd "frozen". SO: I, Robert Ramey, hereby declare: a) the serialization library to be "frozen". b) the documented interface and symantics will only be extended - not changed without notice. c) should any program which depends upon the published interface and semantics fail to work or stop working - I will acknowledge that this is a BUG and endeavor to fix it. d) Going further (specific to the serialization library) - the intent of the serialization library is that newer version be able to load files saved by all previous versions. Any case where this fails will be acknowledged as a BUG. I would ask that library authors that cannot make a similar pledge include a disclaimer in thier documentation and header files something on the order of: "I (the author) expect to make future changes in this library. These changes may have the effect that in the future you're program will fail to compile, link, and/or execute as expected. Since I don't know who might use this library, it is impractical for me to notify you - Sorry about that - Good Luck." That would permit me as a user to take appropriate precautions.

This does discourage breaking changes (in those libs), and as far as I can tell achieves your goals, except that:

A) breaking changes are detected as soon as they occur, and

I disagree here - see above.

B) it allows for breaking changes in non-frozen libs to be treated as features and not bugs.

LOL - this view point is shared by many, perhaps the majority, of people in the software development community. It is the bane of modern software, leading to composition of components that together produce, quirky applications that can be made work only with a disproportional amount off effort and frustration. Robert Ramey

on Tue Jul 15 2008, "Emil Dotchevski" <emil-AT-revergestudios.com> wrote:

On Tue, Jul 15, 2008 at 5:52 PM, Robert Ramey <ramey@rrsd.com> wrote:

...

Here is where we differ. Now when someone checks in a breaking change. errors pop up all over the place in test results that the author who caused the problem doesn't have any reason to check. He who has had his library broken has to investigate the cause of the sudden breakage and trace down to its source and then complain. This is a huge pain in the neck and costs a lot of time and frustration.

You're making a big assumption here, which is that the breaking change is a bug.

Here is an example: adding the Exception library "broke" several other libraries that were throwing ints or enums through boost::throw_exception. The fact is that boost::throw_exception has always required that its argument is of type that derives from std::exception, but it did nothing to enforce this requirement. Now it does enforce it which exposed the bugs in the other libraries. This is a good thing.

That was one of the kinds of cases I had in mind when wondering if it was a good idea to rely on dependent libraries' tests to discover problems in a library. -- Dave Abrahams BoostPro Computing http://www.boostpro.com

on Tue Jul 15 2008, "Emil Dotchevski" <emil-AT-revergestudios.com> wrote:

On Tue, Jul 15, 2008 at 7:11 PM, David Abrahams <dave@boostpro.com> wrote:

...

on Tue Jul 15 2008, "Emil Dotchevski" <emil-AT-revergestudios.com> wrote:

...

Here is an example: adding the Exception library "broke" several other libraries that were throwing ints or enums through boost::throw_exception. The fact is that boost::throw_exception has always required that its argument is of type that derives from std::exception, but it did nothing to enforce this requirement. Now it does enforce it which exposed the bugs in the other libraries. This is a good thing.

That was one of the kinds of cases I had in mind when wondering if it was a good idea to rely on dependent libraries' tests to discover problems in a library.

As opposed to?

I don't understand your question.

I mean, it's not like you want to rely on other libraries to catch your bugs, but you can't be 101% sure you're not using other libraries inappropriately.

I was talking about relying on dependent libraries catching bugs in a dependency (e.g. serialization's tests uncovering breakage in type traits). Sounds like you're talking about the other direction, sort of.

For example, you might depend on an implementation detail of another library without knowing it (note that "not knowing it" isn't always a matter of being careless.)

It isn't?

This might become source of regressions, which are typically undetected until the implementation of the dependent library changes.

Sure. What's your point? -- Dave Abrahams BoostPro Computing http://www.boostpro.com

Emil Dotchevski wrote:

That it is a bad idea to avoid testing an (even stable) library against the (unstable) trunk just because this may produce bogus failures.

I don't see my proposal as avoiding testnig. In my proposal the each library runs all its tests. When merged into release ALL the tests are run there by detected any unintentional and/or unannounced / unaddressed interface changes. All the tests being run now are run under my proposal. Its just that the testing procedure more effectively uses the available resources and better serves developers. Robert Ramey

Emil Dotchevski wrote:

Then perhaps I didn't understand your proposal. Can you clarify the following:

" a) Testing on the trunk is not as helpful as it should be. My tests results fluctuate all the time as changes in other libraries ripple through to my tests.

Proposal:All tests for a particular library should be run against the latest or next release. "

I read it as you don't want to test against trunk and instead you want to test against the last and the next release.

I envision the following: a) a "release ready" version branch or whatever. This version pass all tests or failing tests are marked up - its "perfect" (lol) b) I make a change in my library, and test against the "release ready" version. This is what I meant by testing against latest or next release. Any failure have to be due to my changes and only my changes. I continue in the loop until it is established that merging my lates "oevre" into the "release ready" version will result in a step forward. c) I ask the release manager for permission to do the merge. Assuming that the "release ready" version is not in a state of flux, he will say yes. d) I'll do the merge and all the boost tests will be run on the "release ready" version - exactly as they are now. e) First we shouldn't have any failures in the library just merged in as that's what I've been testing all along so far. f) Any new failures in any library have to be result of the recent merging of my library. Now its my job to investigate how I broke the interface and/or semantics. It could also be that other libraries are depending on library implemention details or it could be that interface/semantics weren't enforced but are now. in this case a new library test should be written and authors of the dependent libraries need to make adjustments. g) Its also possible that I make the mistake of changing the interface and/or semantics (intentionally or not) without making provision for dependent libraries and applications. The resolution of this situation will be subject to the usual rules for arm wrestling. At the end of this process either the dependent libraries are updated or the merge is backed out of the "release version" There is no test run in the current system which is not run in the proposed system. Instead of carpet bombing approach to testing, its more the "scientific experiment" approach to testing where one variable is changed while others are held constant. Again, the advantages: a) No need/concept for "point release" for fixups. The current "release version" IS the "point release" b) Library authors can contribute their improvements on thier own schedule without having to get in lock step with everyone else. c) Library authors get much more useful information from the tests d) Much less time needs to be consumed to run tests. e) Quarterly releases become relatively simple. f) Library authors don't feel tempted to "cut corners" to make sure their improvements get into the release. Thier improvements will get into the release version as soon as they are ready. g) Users who need the latest bug fixes can download the current "release version" I'm sorry the discussion got somewhat side tracked on this issue of interface/semantic immutability. (OK, it was my fault). Its only somewhat related. I don't think that the fact that some libraries may intentionally modifiy interface/semantics doesn't diminish the utility of this proposal. Robert Ramey

Ilya Sokolov wrote:

Robert Ramey wrote:

...

[snip]

I envision the following:

a) a "release ready" version branch or whatever. This version pass all tests or failing tests are marked up - its "perfect" (lol)

b) I make a change in my library, and test against the "release ready" version.

It is not clear to me who will test 'against the "release ready" version', you or testers? If testers, than you need one tester for each library and I don't believe boost have such resources.

OK - now we're moving beyond discussing the merit of the idea to discussion its praticality - a whole new discussion. Of course I'm game. On my own system there's no problem. I just have a "release ready" boost and run the tests on the compilers that I have. The issue is when I want to see tests run on other compilers. I would imagine a process similar to the following: a) I upload to the trunk. A tester runs his script. Currently the test script which syncronises his local system with the trunk and runs the bjam tests. In my proposal, the tester would maintain a "release ready version" on his machine. The script would do the following: a) determine which libraries have changed since the last time he tested. b) For each changed library: i) the equivalent of the SVN "switch" command would be invoked to sync up THAT library with the trunk. ii) bjam test script would be run for only that library. iii) After the test, SVN switch would be reversed. This would entail a lot less. Since one small change in a common header wouldn't trigger testing all the libraries. Futhermore - the testing could, and should be a lot more exhaustive than it is now. Here is a plug for my library_status program which produces a table for a library which includes ALL build configurations - not just debug with dynamic libraries. See www.rrsd.com (boost) for an example of the output this program produces. This helps address the problem where I test for debug - only but the program turns out to fail in release or some other build. This has been he source of much frustration with the serialization library. Now second phase. The release manager gives me permission to roll in my changes into the "release ready" branch. The testing is identical to the current system - there is no "SVN switch". The tester signs up for either trunk testing or for release testing - which is what he does now. In short, implementing this would require a different and more intricate trunk testing script. This is simple to state and to describe - but would in practice be somewhat tricky due to the following: a) Library code not found in one directory so doing an SVN "switch" is not just a one liner. b) I seems to me that an SVN switch in fact does a merger - which can lead to conflicts. And switching back might result in a change in the library. I suspect these issue could be addressed by more careful investigation of the details of SVN usage. So that is more or less how I would envision this testing program being implemented. Robert Ramey

On Jul 17, 2008, at 4:43 PM, Ilya Sokolov wrote:

Robert Ramey wrote:

...

[snip]

In short, implementing this would require a different and more intricate trunk testing script. This is simple to state and to describe - but would in practice be somewhat tricky due to the following: a) Library code not found in one directory

I think this is the biggest issue and it prevents many ideas to work. Perhaps, we should solve it first?

We're working on this so-called "modularization" of Boost as part of the Boost-CMake project. Eventually, every library will be contained within a single directory tree, and will describe its dependencies on other libraries. - Doug

On Fri, 2008-07-18 at 08:10 +0400, Ilya Sokolov wrote:

Doug Gregor wrote:

...

We're working on this so-called "modularization" of Boost as part of the Boost-CMake project. Eventually, every library will be contained within a single directory tree, and will describe its dependencies on other libraries.

It is perfectly doable in boost.build also. Does anybody working on it?

Not that I know of. If someone is going to work on this, we should coordinate the efforts across build systems to get to the right modular structure for Boost. - Doug

On Fri, 2008-07-18 at 09:45 -0500, Rene Rivera wrote:

Douglas Gregor wrote:

...

On Fri, 2008-07-18 at 08:10 +0400, Ilya Sokolov wrote:

...

Doug Gregor wrote:

...

We're working on this so-called "modularization" of Boost as part of the Boost-CMake project. Eventually, every library will be contained within a single directory tree, and will describe its dependencies on other libraries. It is perfectly doable in boost.build also. Does anybody working on it?

Not that I know of. If someone is going to work on this, we should coordinate the efforts across build systems to get to the right modular structure for Boost.

Perhaps you could define what you mean by modular.

A modular library is one in which all of the files corresponding to that library are in a single directory. Practically speaking, it means moving library-specific headers from the top-level boost/whatever into library-specific directories, then stating somehow the inter-library dependencies. - Doug

On Fri, 2008-07-18 at 13:23 +0100, Daniel James wrote:

2008/7/17 Doug Gregor <dgregor@osl.iu.edu>:

...

We're working on this so-called "modularization" of Boost as part of the Boost-CMake project. Eventually, every library will be contained within a single directory tree, and will describe its dependencies on other libraries.

Have you made any plans for the documentation? If boost is modularized, will the documentation in 'doc/html' be split back into separate libraries, or would we keep the generated documentation outside of the modules?

Right now, the generated documentation is going to live outside of the modules. The problem isn't on the CMake side---we can easily generate whatever commands we need to drive the BoostBook toolchain---but that BoostBook/DocBook doesn't really work well as a modular system. The problem is that, when generating the documentation separately, we don't get the inter-library links that we'd like. Moreover, the HTML files that the DocBook XSL generates aren't currently in a form that easily permits side-by-side installation of documentation for each library separately and, even if we did, we need to deal with the problem of generating a table of contents and/or index. So, while I'd like modular documentation generation, it's going to need some serious work on the BoostBook side that I'm not prepared to do. Of course, help would be appreciated :) On the plus side, we can generate Unix man pages in a modular fashion. I'd like to do this by default on Unix targets, because it's nice to be able to write, "man boost::function" and get at the reference documentation. - Doug

On Fri, 2008-07-18 at 15:53 +0100, Daniel James wrote:

2008/7/18 Douglas Gregor <dgregor@osl.iu.edu>:

...

Right now, the generated documentation is going to live outside of the modules. The problem isn't on the CMake side---we can easily generate whatever commands we need to drive the BoostBook toolchain---but that BoostBook/DocBook doesn't really work well as a modular system. The problem is that, when generating the documentation separately, we don't get the inter-library links that we'd like.

A while I ago I was looking at the mechanisms for linking to files. Steven Watanabe suggested a patch to create links relative to boost root:

https://svn.boost.org/trac/boost/ticket/1166

It's clear that I was stumbling around the idea. I was going to try to get something into 1.36, but I discovered problems with the implementation and had other priorities, so I left it for 1.37. If boost is going to be more modular, I think it would be possible to do adapt the idea, using a custom URL along the lines of 'boost://module/path' which could either generate relative links or link to the website, depending on build parameters.

Interesting. That seems feasible.

Of course, that's for linking to files. I know there are multiple mechanisms in docbook for linking between separate docbook units, but when I looked at them, they seemed complicated and awkward to use. You probably know a lot more about them than I do.

Well, we could certainly consider turning some of the BoostBook and DocBook linking entities (e.g., <classname>) into URLs.

...

Moreover, the HTML files that the DocBook XSL generates aren't currently in a form that easily permits side-by-side installation of documentation for each library separately and, even if we did, we need to deal with the problem of generating a table of contents and/or index.

We have to pull together documentation generated by several different methods, so I don't know if a docbook based solution would be appropriate.

That causes some trouble for us, given that we're entirely based on DocBook at the moment :) Perhaps there's some post-processing step we could perform on the HTML that would achieve the same goal. - Doug

David Abrahams:

That was one of the kinds of cases I had in mind when wondering if it was a good idea to rely on dependent libraries' tests to discover problems in a library.

Having dependent libraries act as regression tests is a good thing. It increases the test coverage and helps us uncover regressions before our users.

----- Original Message ----- From: "Peter Dimov" <pdimov@pdimov.com> To: <boost@lists.boost.org> Sent: Wednesday, July 16, 2008 10:17 AM Subject: Re: [boost] [1.36.0] Libraries with unmerged changes?

David Abrahams:

...

That was one of the kinds of cases I had in mind when wondering if it was a good idea to rely on dependent libraries' tests to discover problems in a library.

Having dependent libraries act as regression tests is a good thing. It increases the test coverage and helps us uncover regressions before our users.

Hi, You are right, when you increase the test coverage you reduce the risck of errors for new users, but this do not protect the current user from incompatible evolutions. I would like to know, as a user, if all the test done by developpers themselfs or by the testers on the release branch help to identify possible regressions on the user code, and if these regressions will be explicitly described on the release contents. One way to detect some incompatible evolutions could be to run the tests from the preceding release (1.35) with the new release headers and sources (1.36). I don't know SVN enough to know if such a view (snapshot?) is easy to create. If all the test and examples where in a separate directory this will be surely easier to do. The cost of making these test work without modifying at all the new release, will give us an idea of the cost the users will have on their migrations. Vicente

Emil Dotchevski wrote:

On Tue, Jul 15, 2008 at 5:52 PM, Robert Ramey <ramey@rrsd.com> wrote:

...

Here is where we differ. Now when someone checks in a breaking change. errors pop up all over the place in test results that the author who caused the problem doesn't have any reason to check. He who has had his library broken has to investigate the cause of the sudden breakage and trace down to its source and then complain. This is a huge pain in the neck and costs a lot of time and frustration.

You're making a big assumption here, which is that the breaking change is a bug.

LOL - I call it a bug - you can call it a feature. Regardless, it is an (unannounced) interface change.

Here is an example: adding the Exception library "broke" several other libraries that were throwing ints or enums through boost::throw_exception. The fact is that boost::throw_exception has always required that its argument is of type that derives from std::exception, but it did nothing to enforce this requirement. Now it does enforce it which exposed the bugs in the other libraries. This is a good thing.

This isn't the case being discussed here. Of course a developer can't be responsible for usage of the library which is not in accordance with it's interface and semantics.

In your mind, shouldn't the maintainer of each Boost library be responsible for investigating errors in their own tests, even though it is pain in the neck and costs a lot of time and frustration?

Of course he's responsable. But the job is bad enough without random hand grenades being tossed into the mix.

...

I would ask that library authors that cannot make a similar pledge include a disclaimer in thier documentation and header files something on the order of: ...

You can ask anything you want and you can assume anything you want about Boost libraries, but the fact is that they do change and occasionally breaking changes are introduced,

I'll consider that a disclaimer. I don't think you can speak for other library authors on this point. I know you can't speak for me here. I'll say it again: If anyone discovers an iterface/semantic change in the serialization library - it will be considered a bug. And I won't unleash changes in interface/semantics except under the most extraordinary circumstances. So far this has never occured.

which may or may not be regressions.

Shouldn't we have release procedures that address this _fact_?

And that's the problem with the current proceedures. Changes in one library break other libraries and there is no obvious method of knowing the cause of the problem. My proposal DOES address this when interface breaking library is rolled in to the release. At this point all new test failures must be due to such an interface change. They can then be addressed one way or the other without every library author having to rediscover the cause of the problem. I don't think the issues you've raised argue against the utiltiy of my proposals. Rather the contrary. We'll have to agree to disagree. Robert Ramey

On Tue, Jul 15, 2008 at 10:31 PM, David Abrahams <dave@boostpro.com> wrote:

...

...

On Tue, Jul 15, 2008 at 5:52 PM, Robert Ramey <ramey@rrsd.com> wrote: You're making a big assumption here, which is that the breaking change is a bug.

LOL - I call it a bug - you can call it a feature. Regardless, it is an (unannounced) interface change.

Whether it's announced or not matters a lot, but in this conversation both you and Emil have consistently failed to make a distinction AFAICT.

Let's say that the interface of boost::filesystem::remove changes from returning bool to returning nothing (void). In this case: - Can we label the change a bug, simply because it's a "breaking" change? - Don't we want to detect related failures ASAP, as opposed to waiting until the change gets merged in the release branch? - What difference does it make whether or not the change was "announced"? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

Peter Dimov wrote:

Robert Ramey:

...

Here is where we differ. Now when someone checks in a breaking change. errors pop up all over the place in test results that the author who caused the problem doesn't have any reason to check. He who has had his library broken has to investigate the cause of the sudden breakage and trace down to its source and then complain. This is a huge pain in the neck and costs a lot of time and frustration.

What's the alternative? In Boost release 1.36, libfoo 1.36 has to work against Boost 1.36, not Boost 1.35.

In my view it should work against both. If not there's a bug.

Testing it only against Boost 1.35 allows one to be smug and claim that any failures aren't one's fault,

LOL - well there is that. But note that I'm not suggesting that this be the only testing done.

but doesn't help the release process.

Trunk does, by testing tentative libfoo 1.36 against tentative Boost 1.36.

Sort of.

Exactly. That's my complaint about it. One reason my proposal isn't as clear as it should be is that the current concempt of 1.35, 1.36 would be a little blurred. Given a "release ready version" which is used for testing and ready for release when the quarter comes aroud effectively means that there is a release 1.35.1, 135.2, 135.3 .... each time a tested library is merged in. The only thing special about the 1.36 release is that it would be packaged in a more complete form , tarball, etc. Robert Ramey

on Tue Jul 15 2008, "Robert Ramey" <ramey-AT-rrsd.com> wrote:

I, Robert Ramey, hereby declare:

a) the serialization library to be "frozen". b) the documented interface and symantics will only be extended - not changed without notice. c) should any program which depends upon the published interface and semantics fail to work or stop working - I will acknowledge that this is a BUG and endeavor to fix it. d) Going further (specific to the serialization library) - the intent of the serialization library is that newer version be able to load files saved by all previous versions. Any case where this fails will be acknowledged as a BUG.

I would ask that library authors that cannot make a similar pledge include a disclaimer in thier documentation and header files something on the order of:

"I (the author) expect to make future changes in this library. These changes may have the effect that in the future you're program will fail to compile, link, and/or execute as expected. Since I don't know who might use this library, it is impractical for me to notify you - Sorry about that - Good Luck."

That would permit me as a user to take appropriate precautions.

I'm sure everyone would make the same pledge as you, as long as it has the same back door clause allowing semantic changes "with notice." ;-) At least that's how I read your pledge. If you mean something else you should try to clarify it. -- Dave Abrahams BoostPro Computing http://www.boostpro.com

on Wed Jul 16 2008, "Robert Ramey" <ramey-AT-rrsd.com> wrote:

David Abrahams wrote:

...

on Tue Jul 15 2008, "Robert Ramey" <ramey-AT-rrsd.com> wrote:

...

I, Robert Ramey, hereby declare:

a) the serialization library to be "frozen". b) the documented interface and symantics will only be extended - not changed without notice. c) should any program which depends upon the published interface and semantics fail to work or stop working - I will acknowledge that this is a BUG and endeavor to fix it. d) Going further (specific to the serialization library) - the intent of the serialization library is that newer version be able to load files saved by all previous versions. Any case where this fails will be acknowledged as a BUG.

I would ask that library authors that cannot make a similar pledge include a disclaimer in thier documentation and header files something on the order of:

"I (the author) expect to make future changes in this library. These changes may have the effect that in the future you're program will fail to compile, link, and/or execute as expected. Since I don't know who might use this library, it is impractical for me to notify you - Sorry about that - Good Luck."

That would permit me as a user to take appropriate precautions.

I'm sure everyone would make the same pledge as you, as long as it has the same back door clause allowing semantic changes "with notice." ;-)

At least that's how I read your pledge. If you mean something else you should try to clarify it.

Personally I don't mean "with notice". I mean exactly what I said.

Sorry. It sounded, when you said the semantics wouldn't be changed without notice, that you meant you might change them "with notice." Personally, that's what I would do/support, with a stricter definition of "with notice" of course.

Personally, I'm really relucant make these kinds of changes. However, I do recognise that in spite of the best of intentions they do occur. To me a canonical example is auto_ptr. Over time it has come to be seen that there are some problems with the interface/semantics. Those in charge (whoever they are), I believe have chosen to make differently named entity to address the situation. To me, this is this a good example of how these situations should be handled.

Sometimes that's impractical, but it's great when it works.

Also to be fair, the serialization library has been around a while and we didn't find any agregious errors of this kind. (This is likely due in large part to the boost reviewing process). So its much easier for me to make un-qualified pledge as the above than it would be for a brand new library.

Actually, the disclaimer is a lot more interesting. Suppose that boost asked for (a less provacatively worded) disclaimer for authors who want to be able to do this. Something like:

".... library is a new library. As it becomes more widely used, and we get more feed back from real users. We expect that we may want to make some modifications to some of the interface and/or sematics of the library. We will endeavor to avoid this, but sh*t happens. So please be aware of this and double check the documentation and release notes when moving to a more recent version of this library. Perhaps in the future, we will be able to guarentee that the interface/semantics of the library will not change."

more or less.

I think a blanket statement like that about all Boost libraries is a good idea. Even some of our oldest and most stable libraries change their semantics in small or large ways occasionally. SmartPtr comes to mind. One reason to make such changes is that a *slightly* different version of the library is now in the C++ standard or WP or a TR.

I don't want to get tooooooo serious about this. But I think really do believe that modern software engineering is too much like "traditional engineering" where we build and test. I would like to see it more like "mathematics" where things are proved infallible by construction.

I'm very pleased to hear you say that.

This difference crops up unexpectedly from time to time - e.g. what is the mean of a failure in "assert" and how should it be dealt with. Of course we're off topic, and of course I'm way out of sync with the rest of the world,

Maybe -- but not with me, on that point.

so no need for anyone to point this out. I just like to have my say.

Don't we all ;-) -- Dave Abrahams BoostPro Computing http://www.boostpro.com

I think that instead of formal disclaimer, we can adopt some kind of rating for the stability/matureness of each library. Something like "new" / "mature" / "stable"?

actually as "disclaimer" in the introduction of the library is probably just fine. My concern is that I felt, that some developer's (not just boost) don't appreciate thier libraries are to other people and underestimate the impact and inconvenience that these changes cause. Just puting in such a disclaimer is probably enough to remind the developer to ask himself - "wait a minute - if I do that won't and old program fail in a silent way". And of course these kinds of discussions sometimes make an impression. Robert Ramey

One of the stated purposes of Boost is as a test bed for libraries before they are considered for standardization. So I don't think that the disclaimer says anything new.

I suppose that's true. But for me, boost is the source of well documented and tested code that I can count on to "just work". This is key to me - that is the source of my perspective. Robert Ramey

David Abrahams wrote:

Most developers don't break interfaces lightly, but occasionally a breaking interface change can be better for the overall health of software. At least two of my libraries have had a ground-up redesign since they were accepted into Boost and I believe that they are better, easier to use, and the revision produced minimal additional frustration or effort for users.

Hmmm, I wasn't aware of this. It this redesign redefine existing interface/semantics or define new ones. Did an attempt to compile an old program fail with some sort of indication. I don't think boost is a big offender in this area. Generally when it has happened the past, is usually a mistake or unavoidable. I also believe that the boost testing process - though I have my complaints about it- is very helpful in limiting this situation. I guess my position is I recognise that breaking interface/semantics is sometimes unavoidable. I just think that the repercussions are taken way to lightly by many developers. I also believe that its often done when not really necessary.

Also, avoiding all interface breakage may restrict a developer's flexibility more than you imagine. Consider:

* Adding an optional argument to a function or an optional class template argument, which should be a non-breaking change for most everybody, can break user code.

* Adding an overload can break user code.

* Adding a new name to a namespace can break user code.

I"m sure I could do all of these things. Generally I would consider it a bug. I concede that in such a case I mght want to make different kind of change - but it hasn't happend yet.

* Will you continue to support MSVC6 et al forever? :-)

LOL - now that is a very interesting new topic. I would say I intend to support MSVC6 as long as it cost me nothing to do so. Stripping out some of the stuff which supports MSVC6 would make the implemenation somewhat cleaner. But it would require a whole new round of testing compiler by compiler and the net result would have nothing more than we have now. So there's no bang for the buck. Borland 5.64 is another case. Turns out the borland library would pass all tests if two compilation bugs were fixed. I would like to do that - (bang for the buck) but haven't been able to get my bjam setup working for borland. The borland serialization library is also very interesting in this context as well. When spirit moved to 1.8 from 1.6 borland couldn't compile the xml_?archive (the lastest version of borland still can't). Getting xml_?archive to work with borland was toture with spirt 1.6 - there was/is no way that I'm ever going to do that again. The developer's of spirit had the visiion (I guess they took the pledge) to leave spirit 1.6 around. So I stil only have one xml_?archive code base which works with both spirit 1.6 and spirit 1.8. Now THAT's professional software development which we should all be aiming for. I believe that the authors want to make some interface/semantic changes in the old names and they've announced that. I can live with this - using conditional compiles - but it would be preferable to use new names. I'm getting off the topic of my proposal for "sugical testing" vs "carpet bombimg testing" but this is an interesting topic for me. Robert Ramey

...

...

Also, avoiding all interface breakage may restrict a developer's flexibility more than you imagine. Consider:

...

* Adding an optional argument to a function or an optional class template argument, which should be a non-breaking change for most everybody, can break user code.

...

* Adding an overload can break user code.

...

* Adding a new name to a namespace can break user code.

I"m sure I could do all of these things.

I'm not sure what you mean.

What I mean is that I could easily do all these things unintentionally

...

Generally I would consider it a bug.

In my code.

In your code or the user's? If yours, are you seriously willing to say you won't introduce any new functions or types into an existing namespace?

From time to time I would expect the library to be extended by adding new functions and perhaps new types into an existing namespace. It has never occurred to me to that this could break user code - but now that you mention it I suppose it could if users had added their own stuff to the archive namespace. However, I would probably consider this a user error in that it violates the intention of name spaces to avoid just this problem.

...

I concede that in such a case I mght want to make different kind of change - but it hasn't happend yet.

...

* Will you continue to support MSVC6 et al forever? :-)

LOL - now that is a very interesting new topic.

Not entirely new. If you drop support for MSVC6, you have made a breaking change for some users.

...

I would say I intend to support MSVC6 as long as it cost me nothing to do so.

So if it began to cost you something, you'd drop support even though it would be a breaking change for some users?

And of course, that would be OK. Even in this case I might want to leave around the old version. But, I guess that my pledge would have to extended to cover this case. On the other hand, the "pledge" is mostly a retorical device to make a point so I'd rather not turn it into the tax code. Robert Ramey

----- Original Message ----- From: "David Abrahams" <dave@boostpro.com> To: <boost@lists.boost.org> Sent: Wednesday, July 16, 2008 11:18 PM Subject: Re: [boost] [1.36.0] Libraries with unmerged changes?

...

...

From time to time I would expect the library to be extended by adding new functions and perhaps new types into an existing namespace. It has never occurred to me to that this could break user code - but now that you mention it I suppose it could if users had added their own stuff to the archive namespace.

That is normally a no-no. However

using namespace boost::archive; struct foo {};

if boost::archive acquires a "foo" there will be ambiguity.

...

However, I would probably consider this a user error in that it violates the intention of name spaces to avoid just this problem.

Hi, Is there a way the user can write their code to avoid this possible ambiguity? Is there a way the developper can add a new interface avoiding this possible ambiguity on the user code? How the C++ standard library does to avoid this kind of ambiguity in user code? Does this banish the use of using in user code if he/she wants to avoid incompatibilities with newer releases? Vicente

--------------------------- Vicente Juan Botet Escriba ----- Original Message ----- From: "Robert Ramey" <ramey@rrsd.com> To: <boost@lists.boost.org> Sent: Thursday, July 17, 2008 6:55 PM Subject: Re: [boost] [1.36.0] Libraries with unmerged changes?

vicente.botet wrote:

...

...

...

However, I would probably consider this a user error in that it violates the intention of name spaces to avoid just this problem.

Hi,

Is there a way the user can write their code to avoid this possible ambiguity? Is there a way the developper can add a new interface avoiding this possible ambiguity on the user code? How the C++ standard library does to avoid this kind of ambiguity in user code?

This is easy, just don't put any of your own stuff into the the namespace that the library uses.

...

Does this banish the use of using in user code if he/she wants to avoid incompatibilities with newer releases?

If you never put any of your own stuff in to the boost:: or std:: namespaces, you shouldn't have this problem.

If you use "using <namespace>" you could still have aproblem if one of your names accidently matches something this the namespace being used. For this reason, I don't particularly like using "using <namespace>" myself but rather just spell out the whole thing like boost::filesystem:: ...

Here the user do not put any on into the std namespace. using namespace std; struct shared_ptr {}; My question was, How the new C++0x standard library avoid regression on the user code when the user migrates to C++0x ? Vicente

On Thu, Jul 17, 2008 at 9:09 AM, vicente.botet <vicente.botet@wanadoo.fr> wrote:

Here the user do not put any on into the std namespace. using namespace std; struct shared_ptr {};

Also, ADL will pull in user code without using using. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

Vladimir Prus wrote:

...

OTOH, there were a bunch of changes done by others, like ®¦ -> (c) replacements, and changes in properties set, which I would have expected to be merged to release branch by whoever made the commit in the first place. Anyway, I've merged those, for program_options, too.

Um, some of those were me. My bad. Thanks! -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.