Re: [boost] Boost Development Environment proposal

From: Robert Ramey (ramey_at_[hidden])
Date: 2007-06-03 12:54:06

Whoa - HUGE feature creep.

I think that Beman's proposal has just the right scope and it shouldn't
be expanded.  In fact I think it can be simplified a little bit.

I believe that with beman's proposal:

a) releases can occur much more frequently - on the order of once/month.
b) this will ovbviate the need for separate library releases.

One thing I failed to mention is the version numbering scheme.  Something
along the following lines could be used.

boost 1.<breaking change index>.<release number>

so we (soon) have 1.34.1

every release which doesn't break any interface would be
1.34.2, 1.34.3 ....
(even addtion of a new library would just update the last digits).

the next release with a breaking change would be
1.35.0

So a library user could guarentee that his application works
with any    1.34.3 <= boost version <1.35.  This release
version would also be available as a library call so that
apps could guarentee that DLLS build with other releases
can be expected to work.  An applicaition developer
can also include compile time checks so that if he
moves to another boost version, he'll know that he'll
have to re-run his test or what ever.

Of course, each library author could also have is
own similar scheme for making available the library
version.  But this would very depending on the library
and wouldn't necessarily be a boost wide thing.  In
any case, it would be totally orthogonal to the current
proposal.

Robert Ramey

Edward Diener wrote:
> Beman Dawes wrote:
>> There is a fresh draft of a Boost Development Environment proposal
>> up at http://mysite.verizon.net/beman/development_environment.html
>
> Here are some suggestions to promote the idea that individual Boost
> libraries can be released between full releases of the entire Boost
> set
> of libraries, as relating to your item "It is reasonably easy to
> release
> of subsets of Boost."
>
> These suggestions are admittedly all given from this end-user's
> perspective, rather than a Boost developer's perspective , but the
> suggestions are well-meant and are not given to be a burden on Boost
> developers.

....