On Feb 11, 2005, at 10:39 PM, Neil Graham wrote:
There is clear interest in modernizing the build system (and I'm +1 on that, BTW), and it doesn't sound like there will be any shortage of people to help get the work done. That, in itself, wouldn't seem to necessitate a 3.0.
Whether or not modernizing the build system requires a 3.0 release may depend on whether the changes required to Platform are interface compatible, and whether, indeed, platform is part of the public interface at all (this gets back to our problem of not having an explicit distinction between public and private headers, which is another reason to make a clean break with past notions of interface stability.). It's certainly the case that in order to fix the build/port system, we've got to do a major refactoring of "Platform", as one of the biggest problems is that the notion of Platform is too monolithic: we need a finer grained mechanism for deciding what works where. If need, however, we may be able to create a new (perhaps compatible?) Platform shim that sits atop these finer grained mechanisms.
Can we fix the build/port system without breaking the interface? Perhaps. I don't think we'll know until we get into it.
The best argument for 3.0 would be that there is compelling new functionality.
- DOM3 makes a good argument for a "3" release.
- A rejuvenated up build system is icing on the cakeXInclude and XPath would be awesome, but they could wait for a 3.1 or 3.2, also.
One idea is that in doing doing a 3.0 release, we could relax some of our notions of compatibility. The 2.x branch is still there, and still supports all those old crusty compilers. But 3.x could perhaps require a more modern C++ with assumed support for STL and namespaces (if needed to get us to xpath).
James
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
