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