[boost] Boost 2 - development in long term

From: Pavel Vozenilek (pavel_vozenilek_at_[hidden])
Date: 2004-03-11 06:25:37

Described is an idea how Boost can move on in the future.
By future I mean 2-5 years, definitely not tomorrow or next
month.

Support for sub-standard compilers is taking away lot
of time and energy of library writers. It also makes result
code quite hard to understand and modify. Shouldn't only
so many people be stuck with old equipment...

What could be done:
  - create branch or fork of Boost in CVS, say Boost 2.

  - this project will have exactly the same structure
    as current Boost (directories/libraries/tests).

  - the project will be initially empty.

  - one by one, libraries will be removed of kludges,
    and workarounds (all of them, w/o exceptions) and copied
    into Boost 2. This includes:
       - fixes for nonconforming compilers (#ifdef BOOST_MSVC ...)
       - fixes for substandard STL (e.g. old Dinkumware)
       - fixes to deal with missing exception support

  - the converted libraries will be tested only with very recent
    compilers which are supposed to be conformant (GCC 3.4,
    VC8, Intel C++ 8, Metrowerks 9.2, Comeau).

Why this may work:
  - all existing infrastructure (the tests) could be reused
    w/o change.

  - no need to deal with non-standard systems makes
    the cleanup less time consuming.

  - with no need to deal with non-standard systems it may
    be interesting work and fun for library writers, again.

  - compiler vendors may take it as incentive to improve their
    system, rather to rely on people will find workarounds.
    This effect can be already seen today.

What would it require:
  - some site with latest compilers which would continually
    and automatically run all the tests. Not all people have
    access to newest tools.

  - the cleanup could be done by original library author
    or by someone who feels knowledgeable with it.

  - core libraries need to be identified and ported first.

What to do with current Boost 1.XX:
  - the development will continue as it is now, as long
    as needed and feasible (my guess are few years more).

  - new libraries will be added into Boost 1.XX and may
    or may not contain legacy compilers support
    (as it is now). They will be eventually added into
    Boost 2 in 'clean state'.

Problems:
  - how to keep both branches up to date with fixes and
    changes? This is real problem and should be solved
    by requiring every change in Boost 1.XX be considered
    for Boost 2. Backporting from Boost 2 to Boost 1.XX
    would be optional but rare.

    Hopefully most libraries are rather mature and don't
    go through major rewrites. Even if so, making clean
    version should be relatively painless.

  - should there be two sets of documentation? No,
    the documentation should not change except removing
    information about old systems support. This should
    be reasonably easy.

  - woudln't people with old compilers feel abandoned?
    Yes, but development for 1.XX should continue as long
    as needed/feasible. In few years hopefully support for
    VC6 and Borland will dimish.

  - there's no time to do yet more work: this should be long
    term project. Individual libraries can be ported at
    individual pace and independently.

  - code without kludges may not compile on ANY existing
    compiler: so be it. Next version of compiler will
    be hopefully better. Workarounds should be forbidden
    or very, very rare.

Who will benefit of this all:
  - library writers who do not want to support old
    systems (less pressure on them) may spend more time
    with design. This gets more important if more
    powerfull/complex libraries will emerge.

  - users with new compilers (they can be more sure
    the library remains maintainable and may even be able
    to understand its inner, too). Their existing code
    using Boost should compile without changes.

  - compiler vendors will be able catch more errors.

  - standard comittee may be more interested in clean
    code.

  - if/when the world moves to C++0x it will be easier
    to move Boost there (this is beyond horizont of this
    idea though).

What it it all fails:
  - Boost 1.XX should be unaffected by branching and could
    continue as if nothing had happened.

I remind again this idea is about long term development
of Boost. I think it has biggest effect for the effort spent.

/Pavel