[next release] Any new libraries ready for the next release?
Will any new libraries be ready to go in the next release? --Beman
Beman Dawes wrote:
Will any new libraries be ready to go in the next release?
I'm hoping to get proto in. Why do you ask? -- Eric Niebler BoostPro Computing http://www.boostpro.com
Eric Niebler wrote:
Beman Dawes wrote:
Will any new libraries be ready to go in the next release?
I'm hoping to get proto in. Why do you ask?
To determine if the next release is 1.37.0 or 1.36.1, so I can bump the version number. It isn't critical since the version number isn't essential until late in the release cycle, but it is helpful for discussion, tagging subject lines, etc. So at least tentatively, the next release will be 1.37.0. --Beman
on Sun Aug 17 2008, Beman Dawes <bdawes-AT-acm.org> wrote:
Eric Niebler wrote:
Beman Dawes wrote:
Will any new libraries be ready to go in the next release?
I'm hoping to get proto in. Why do you ask?
To determine if the next release is 1.37.0 or 1.36.1, so I can bump the version number.
It isn't critical since the version number isn't essential until late in the release cycle,
How does that work? Does it mean any changes that would be inappropriate in a point release will be merged to release at the last minute? I'm still getting used to the new system. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
on Sun Aug 17 2008, David Abrahams <dave-AT-boostpro.com> wrote:
on Sun Aug 17 2008, Beman Dawes <bdawes-AT-acm.org> wrote:
Eric Niebler wrote:
Beman Dawes wrote:
Will any new libraries be ready to go in the next release?
I'm hoping to get proto in. Why do you ask?
To determine if the next release is 1.37.0 or 1.36.1, so I can bump the version number.
It isn't critical since the version number isn't essential until late in the release cycle,
How does that work? Does it mean any changes that would be inappropriate in a point release will be merged to release at the last minute? I'm still getting used to the new system.
I would really appreciate an answer to this question. So far, it looks to me like we either need to decide that as a policy we're simply not going to do point releases, or we need a separate release branch for each series (e.g. 1.36.x) -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
I'm hoping to get proto in. Why do you ask?
To determine if the next release is 1.37.0 or 1.36.1, so I can bump the version number.
It isn't critical since the version number isn't essential until late in the release cycle,
How does that work? Does it mean any changes that would be inappropriate in a point release will be merged to release at the last minute? I'm still getting used to the new system.
I would really appreciate an answer to this question. So far, it looks to me like we either need to decide that as a policy we're simply not going to do point releases, or we need a separate release branch for each series (e.g. 1.36.x)
Suppose library X has a bug which requires a fix before the next release. And suppose the fix is tested in the trunk and merged into "release ready" version and the "release ready" version is totally retested. Wouldn't just assigning a tag (1.36.1) (or "copy) in SVN parlance) to the current release ready version qualify as a "point release" That is how would this differ from a "point release"? Maybe I've misunderstood what people mean by "point release". Robert Ramey
on Fri Aug 22 2008, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
David Abrahams wrote:
I'm hoping to get proto in. Why do you ask?
To determine if the next release is 1.37.0 or 1.36.1, so I can bump the version number.
It isn't critical since the version number isn't essential until late in the release cycle,
How does that work? Does it mean any changes that would be inappropriate in a point release will be merged to release at the last minute? I'm still getting used to the new system.
I would really appreciate an answer to this question. So far, it looks to me like we either need to decide that as a policy we're simply not going to do point releases, or we need a separate release branch for each series (e.g. 1.36.x)
Suppose library X has a bug which requires a fix before the next release. And suppose the fix is tested in the trunk and merged into "release ready" version and the "release ready" version is totally retested. Wouldn't just assigning a tag (1.36.1) (or "copy) in SVN parlance) to the current release ready version qualify as a "point release" That is how would this differ from a "point release"?
Maybe I've misunderstood what people mean by "point release".
A point release is a release that differs minimally from its numeric predecessor, with the only changes being bugfixes. Users that want a point release explicitly do *not* want new features, new libraries, or other "improvements." Combine that with the fact that library authors may have decided that they need to break backward compatibility in the next non-point release, and I don't see how a point release can be spun off the "release" branch at arbitrary times. I'm not trying to poke holes in the current release process; I would simply like everyone to be very clear about its implications. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
on Fri Aug 22 2008, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
David Abrahams wrote:
I'm hoping to get proto in. Why do you ask? To determine if the next release is 1.37.0 or 1.36.1, so I can bump the version number.
It isn't critical since the version number isn't essential until late in the release cycle, How does that work? Does it mean any changes that would be inappropriate in a point release will be merged to release at the last minute? I'm still getting used to the new system. I would really appreciate an answer to this question. So far, it looks to me like we either need to decide that as a policy we're simply not going to do point releases, or we need a separate release branch for each series (e.g. 1.36.x) Suppose library X has a bug which requires a fix before the next release. And suppose the fix is tested in the trunk and merged into "release ready" version and the "release ready" version is totally retested. Wouldn't just assigning a tag (1.36.1) (or "copy) in SVN parlance) to the current release ready version qualify as a "point release" That is how would this differ from a "point release"?
Maybe I've misunderstood what people mean by "point release".
A point release is a release that differs minimally from its numeric predecessor, with the only changes being bugfixes. Users that want a point release explicitly do *not* want new features, new libraries, or other "improvements." Combine that with the fact that library authors may have decided that they need to break backward compatibility in the next non-point release, and I don't see how a point release can be spun off the "release" branch at arbitrary times.
Good points. It really sounds like it is isn't possible to do point releases unless they are regular planned part of the process with their own people, testing, reporting, and other resources in place on a permanent basis.
I'm not trying to poke holes in the current release process; I would simply like everyone to be very clear about its implications.
Understood. And this discussion is helping to clarify exactly what the current release process is and what it isn't. --Beman
Robert Ramey wrote:
I would really appreciate an answer to this question. So far, it looks to me like we either need to decide that as a policy we're simply not going to do point releases, or we need a separate release branch for each series (e.g. 1.36.x)
Suppose library X has a bug which requires a fix before the next release. And suppose the fix is tested in the trunk and merged into "release ready" version and the "release ready" version is totally retested. Wouldn't just assigning a tag (1.36.1) (or "copy) in SVN parlance) to the current release ready version qualify as a "point release" That is how would this differ from a "point release"?
The release ready branch contains more than just bug fixes, there may be new libraries or significant new features as well? John.
David Abrahams wrote:
on Sun Aug 17 2008, David Abrahams <dave-AT-boostpro.com> wrote:
on Sun Aug 17 2008, Beman Dawes <bdawes-AT-acm.org> wrote:
Eric Niebler wrote:
Beman Dawes wrote:
Will any new libraries be ready to go in the next release?
I'm hoping to get proto in. Why do you ask? To determine if the next release is 1.37.0 or 1.36.1, so I can bump the version number.
It isn't critical since the version number isn't essential until late in the release cycle, How does that work? Does it mean any changes that would be inappropriate in a point release will be merged to release at the last minute? I'm still getting used to the new system.
I would really appreciate an answer to this question. So far, it looks to me like we either need to decide that as a policy we're simply not going to do point releases, or we need a separate release branch for each series (e.g. 1.36.x)
I think we are simply not going to do point releases, until further notice. It isn't so much a matter of policy as a matter of resources. We've got enough resources to do quarterly releases. We don't have enough resources to do quarterly releases and point releases. 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. --Beman
on Sun Aug 24 2008, Beman Dawes <bdawes-AT-acm.org> wrote:
David Abrahams wrote:
on Sun Aug 17 2008, David Abrahams <dave-AT-boostpro.com> wrote:
on Sun Aug 17 2008, Beman Dawes <bdawes-AT-acm.org> wrote:
Eric Niebler wrote:
Beman Dawes wrote:
Will any new libraries be ready to go in the next release?
I'm hoping to get proto in. Why do you ask? To determine if the next release is 1.37.0 or 1.36.1, so I can bump the version number.
It isn't critical since the version number isn't essential until late in the release cycle, How does that work? Does it mean any changes that would be inappropriate in a point release will be merged to release at the last minute? I'm still getting used to the new system.
I would really appreciate an answer to this question. So far, it looks to me like we either need to decide that as a policy we're simply not going to do point releases, or we need a separate release branch for each series (e.g. 1.36.x)
I think we are simply not going to do point releases, until further notice.
It isn't so much a matter of policy as a matter of resources. We've got enough resources to do quarterly releases. We don't have enough resources to do quarterly releases and point releases.
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. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
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.
Note that if any library author want's to do a "point release" all he has to do is to gather up the files and directories which are changed into a zip file and post them somewhere for interested parties. Or, he could create his own branch of the "1.36" tag and label it "1.36.1 - serialization hot fix" (so as not to get intertwined with hot fixes/point releases for other libraries). The current system in no way prohibits or discourages this. I did this for serialization 1.36 version (the zip file method) 5 months before the official boost 1.36 version was released to address the issue of DLLS and multi-threading in the serialization which some users felt was important to them. Seemed to work out for all concerned and didn't place any burden on the boost release manager or process. Robert Ramey
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! John.
John Maddock wrote:
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!
John. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I was thinking the same thing last night as I retired to bed. As a user of Boost who is constantly trying to get clients to adopt the libraries... it would help. I think users would be happy getting full releases each 6-months. If there is a new library that is compelling to use yet isn't in the official release, people can simply add it. I had several clients running Boost.Asio that way for quite a time. I appreciate the push-back from library developers about point releases; however, adoption of libraries by the general public is dependent on stability. This includes non-breaking changes. I have three clients that will not be moving from 1.34.1 anytime soon because of the in-house havoc it will create. If every official release from Boost results in the possibility of breaking changes then the general popularity of the library set will decrease. I would like to say that the increased popularity of Boostpro services (and others) to offer more frequent patched results would increase but thus far my experience with clients would not suggest that. I personally would love to see John's suggestion implemented. It doesn't require additional resources than currently planned and seems to take the users' concerns into account. -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
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
2008/8/27 Bjørn Roald <bjorn@4roald.org>:
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.
Boost is open source so if you want to maintain a stable release you don't need a formal role, you can just do it (under an appropriate name, naturally). This already happens in Debian. Of course, a downside to having third party releases is that it can get very confusing for the casual user. I've recently had that problem with TeX. Some caution is required but if is anything is going to happen for 1.36 it's unlikely that it'll come from 'official' boost. Daniel
Beman Dawes <bdawes <at> acm.org> writes:
Eric Niebler wrote:
Beman Dawes wrote:
Will any new libraries be ready to go in the next release?
I'm hoping to get proto in. Why do you ask?
To determine if the next release is 1.37.0 or 1.36.1, so I can bump the version number.
Wouldn't it be better to keep the minor release numbers for strictly bug-fix, no major API/ABI change type of releases? In my opinion the middle number should always be bumped for planned, quarterly releases. If at one round there is little to add it makes it a good opportunity to compensate in delays from previous releases and to tune the release procedure. It would be great if resources were available to issue bug-fix releases regularly, say as gcc does. As it is bug-fix releases are only issued when they are perceived as inevitable, and a place in the numbering scheme should be kept aside for those. Cheers, Nicola Musatti
On Mon, Aug 18, 2008 at 4:01 PM, Nicola Musatti <Nicola.Musatti@gmail.com> wrote:
Beman Dawes <bdawes <at> acm.org> writes:
Eric Niebler wrote:
Beman Dawes wrote:
Will any new libraries be ready to go in the next release?
I'm hoping to get proto in. Why do you ask?
To determine if the next release is 1.37.0 or 1.36.1, so I can bump the version number.
Wouldn't it be better to keep the minor release numbers for strictly bug-fix, no major API/ABI change type of releases? In my opinion the middle number should always be bumped for planned, quarterly releases. If at one round there is little to add it makes it a good opportunity to compensate in delays from previous releases and to tune the release procedure.
I would agree here. But more to this, for example for people who have standardized on Boost 1.35 for example already, shifting to 1.36 is sometimes just too much to ask to get bug fixes that ought to have been in 1.35.1 -- and besides, it's only been how many months between 1.35 and 1.36 : what happens when people find bugs in 1.35 that aren't fixed in 1.36, does that mean the fix will have to be available in 1.37? I understand that it's a lot harder to maintain multiple versions of libraries especially since changes to libraries are the responsibility of library authors/maintainers. Back-porting (critical) fixes for example from 1.36 to certain libraries in 1.35 to yield 1.35.1 might be a more viable option for users that want to stick with 1.35 while waiting for new libraries in 1.36 to "mature". This introduces some burden to the release manager (if Beman would be the same release manager that will manage a 1.35.1 release) but it also allows for an opportunity to others who would want to try their hand at making a point-release. Having a group of people for example dedicated to back-porting fixes from later releases (or from trunk perhaps) into a bugfix release (which can go out more frequently than a quarterly release, say a bugfix release every week if there are things to push out) for particular release numbers (a team for 1.35, another for 1.36) increases the involvement of those interested and perhaps encourages more contribution from non-authors/maintainers. I don't know though if this is welcome, but I think it's worth a shot.
It would be great if resources were available to issue bug-fix releases regularly, say as gcc does. As it is bug-fix releases are only issued when they are perceived as inevitable, and a place in the numbering scheme should be kept aside for those.
I don't see value in a regular bug-fix release especially if there aren't any bug fixes to push. Unless you're back-porting patches from later releases of existing libraries on a regular basis, then maybe that would be worth a shot. -- Dean Michael C. Berris Software Engineer, Friendster, Inc.
participants (10)
-
Beman Dawes -
Bjørn Roald -
Daniel James -
David Abrahams -
Dean Michael Berris -
Eric Niebler -
John Maddock -
Michael Caisse -
Nicola Musatti -
Robert Ramey