
Robert Ramey writes:
With the new MPL in the main trunk and the updated MPL documentation coming later this week, we've finally come to the point when it's feasible to talk about the branch-for-release date.
Given that there is still some work on regressions to be done, I'd like to aim for the end of the week, let's say Friday, September 17th. Does that sound OK to everybody?
Sounds too optimistic to me.
Well, let's try and see how it goes.
I'm assuming that at this point all library authors/maintainers are finished with the tasks they wanted to perform before the release, minor regression fixes aside. If not, please scream loudly!
That's a reasonable assumption. But ...
One thing that we really have to take care of before branching is long filenames. Could maintainers of the following libraries please fix the corresponding problems listed in detail in http://www.boost.org/regression->logs/inspection_report.html?
archive (serialization) build date_time graph iterator preprocessor property_map python serialization spirit test utility/enable_if
The problem here is that some boost libraries depend on other boost libraries. E.g. serialization depends on spirit, lots of stuff depend on iterator, everything depends on test. So changing names will have lots of secondary effects.
I don't see how. There only two _header files_ that need to be renamed, and they are both in the serialization library: boost/archive/polymorphic_binary_wiarchive.hpp: filename > 31 chars boost/archive/polymorphic_binary_woarchive.hpp: filename > 31 chars
I'm still struggling with the fact that spirit 1.61 depends upon apply_if.hpp which no longer exists. In effect this makes the serialization library unavailable to vc 6.0, borland and others. That's just one case. BTW.
What are others?
These changes will break user code that depends on previous boost versions. So that's another question.
MPL changes, yes. That was a conscious decision, and I don't see how it's relevant to the question of branch-for-release date.
Another issue is that the toolsets have some pending anomalies. Aside from the fact that the toolset documentation is now out of sync with the actual toolsets available and in use,
That's an issue that needs to be taken care of. Could you name the toolsets you are aware of being out-of-sync with the docs?
I'm having problems with all those which use stlport which used to work. I'm still tracking this down.
This is just the stuff I know about. I would say 17 Sep is hopelessly optimistic.
May be a little bit. All other issues aside, how much do you need to get the serialization library only into the state that you would consider releasable? -- Aleksey Gurtovoy MetaCommunications Engineering