Re: [boost] [next release] Any new libraries ready for the nextrelease?

From: Bjørn Roald (bjorn_at_[hidden])
Date: 2008-08-27 04:42:52

John Maddock wrote:
> David Abrahams wrote:
>>> At some point in the future we can reevaluate that. If we change over
>>> to CMake someday, perhaps testing will become so easy that a lot of
>>> resources are freed. Or maybe as we refine the quarterly release
>>> cycle, quarterly releases will become so automatic that we can divert
>>> resources to point releases occasionally. But not now.
>>
>> That's fine with me, as long as we all understand that the new system
>> where there is a single "release" branch does not accomodate point
>> releases.  Should we decide to start making point releases, we'll have
>> to change the system again.
>>
>> Anyway, maybe being able to tell people straight out that Boost
>> doesn't do point releases will help explain things to the many people
>> who have been asking how the current system can work.
>
> I was wondering about this earlier today, what if we alternated point 
> releases and full releases?  We should as Beman says get the current 
> system semi-automatic *first* of course!

I agree in general that point releases are important.  However I get the 
nagging feeling there will always be a conflict of interest between 
moving forward in features and the maintenance of released libraries 
features. 

One question to address here is whether to let library authors and a 
main boost release team focus on the moving forward part and let others 
do the maintenance part as far as mechanizing the point release 
process.  Some collaboration between the two efforts would be natural 
and beneficial for both, but I think it is important that this does not 
become intrusive.  As I see it there are two great reasons for loving 
boost, it move C++ forward and it provide great production quality 
libraries.  I hope both these can be taken properly care of without 
getting in each others way.

The rest of this post is some thoughts on how maintenance for former 
releases could work if it is a separate responsibility from the moving 
forward effort.  If the current boost team are let off the hook as far 
as point releases, who can then maintain the released versions?  
Individuals, organizations, or commercial entities need to be offered 
the needed tools and formal role needed to take responsibility for 
maintenance of one or more released major versions.  These entities may 
be sponsored in the way they like to perform this work.  I think there 
is a clear interest and possible marked for this.  The hope that this is 
possible without making the result end under a closed license or in some 
other way or form of limited distribution. 

Source of fixes would be patches and suggestions for official hot-fixes 
provided by anybody in a systematic way (e.g. trac tickets).  Careful 
merging of none-breaking fixes (trac tickets) from new major releases is 
also a possible source.   Direct work by maintainers of point releases 
should be published so fixes is sufficiently available  for  maintainers 
of other branches.

Test resources are essential and hard to find.  Could testers be set up 
with some sort of master schedule managed by a boost test manager so 
they test various branches/tar-balls as required and report 
appropriately?  That way the maintainer working on a point release could 
as required request testing on wide range of platforms without having 
their own costly setup.  Somebody need to be the manager of test 
resources and give priority as appropriate by controlling the testing 
schedule to make this work.

Some centralized management role in boost community controlling what a 
can go into a point release and what is worthy of a point release seems 
needed.  With this there is a chance of a system that can be recognized 
between the major releases.  I bet the next "future" discussion will be 
of multiple levels of releases so this is subject is something to keep 
attention to.  Multiple levels may allow a 1.34 version with asio and 
expressive but no (or few) breaking changes on old libraries.

Migration tools between major versions of boost is another possible need 
that I think is best left to those that may benefit from making and 
providing them commercially or otherwise.  I do not think the boost 
library developers should need to be concerned with this.

Some additional things that come to my mind is:

Users of boost are developers.  They are lacy and need some help in 
understanding why they should,,and how they go about, getting their 
company to sponsor boost point release maintenance.   A possible idea 
would be web pages explaining to developers and managers that sponsoring 
is optional, but how it will give their developers certain levels of 
attention from maintainers and generally help provide point releases so 
fragile patching or costly moves to new breaking releases can be 
avoided.  I think it is best to avoid open options to pricing as 
developers are lacy and do not bother the extra work of trying to figure 
and argue for an amount that make sense to pay.   Give some fixed 
options with various terms as this is much simpler to relate to.  Each 
maintainer of former releases releases should publish which of the 
options they prefer and support either on their own web page or in some 
agreed way on the boost pages.  The last option sounds better to me but 
will require some official boost management and may be fragile.

Some boost-users (or more likely their lawyers and managers) also would 
like licenses under more  traditional commercial terms.  Don't ask me 
why -- but it seems to be a fact of life.  Companies such as BoostPro 
should be free to be maintainer of released major versions and free to 
dual license as needed to allow all developers to use boost. 

-- 
Bjørn
 
>
> John.
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost