Re: [boost] Boost Development Environment proposal

From: Beman Dawes (bdawes_at_[hidden])
Date: 2007-06-03 18:15:30

Robert Ramey wrote:
> 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.

I avoided specifying an exact schedule; we need to have the flexibility 
to adjust until we find a happy medium that both developers and users 
are comfortable with.

A year ago I was talking about monthly releases. But since then the idea 
has taken hold that we should always maintain a stable, release-ready, 
branch. That makes it much less pressing that we release very quickly, 
so I'm wondering if quarterly releases might be less hectic.

> b) this will ovbviate the need for separate library releases.

Yes. Regardless of the exact schedule, doing releases relatively often 
and on a regular schedule will obviate a lot of the need for separate 
releases.

But, and this is an important point, different sub-communities within 
Boost may have their own reasons for wishing to schedule their main 
release asynchronously compared to the main Boost releases. And as Boost 
continues to grow that becomes more likely. So I really think it is 
useful to be able to do separate releases, even if that facility isn't 
used a great deal at first.

> 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.

I'd like to think about your numbering suggestion above before 
commenting on the specifics. But I do think that if we are going to 
change how we number releases, now might be a good time to do it, and it 
is certainly a good time to talk about version numbering.

Thanks,

--Beman