[filesystem][xpressive] Hotfix patches available for 1.36.0
Hotfix patches are available to fix Boost.Filesystem and Boost.Xpressive [1.36.0] problems. See https://svn.boost.org/trac/boost/wiki/ReleasePractices/HotFixes Providing hotfix patches is something new and experimental for Boost. Please let us know if you find the patches useful or have other comments. Thanks, --Beman
Beman Dawes wrote:
Hotfix patches are available to fix Boost.Filesystem and Boost.Xpressive [1.36.0] problems. See https://svn.boost.org/trac/boost/wiki/ReleasePractices/HotFixes
Providing hotfix patches is something new and experimental for Boost. Please let us know if you find the patches useful or have other comments.
Are these libraries usable without these hotfixes or should they be considered required? At my company we use Boost directly and use libraries that depend on Boost. We push those developers to upgrade their libraries when a new version of Boost is released and we realize that it is a burden on them and us to make the switch to the new versions. Generally this means there is a lag between release and adoption as we cannot move forward with a new version of Boost until all the third party libraries that we interface with upgrade their libraries to the new version of Boost. In my opinion this makes hotfixes worse than useless for us. We might not be able to upgrade to Boost+libraries that use Boost. For instance if library A upgrades to 1.36 plain and library B upgrades to 1.36 plus all or some of the hotfixes. If this compatibility problem occurs and the libraries also provide critical fixes to their own library then I believe we are stuck and must either drop the library, drop boost, or wait for everything to resynchronize. I may be overreacting but this seems very dangerous to me. If there are critical fixes I'd much rather have a point release which we can easily identify to the third party library providers. If the fixes are not critical enough to justify making a point release than they should wait until the next release. Thanks, Michael Marcin
Michael Marcin wrote:
If the fixes are not critical enough to justify making a point release than they should wait until the next release.
So you're against hotfixes. <shrug> I would say, take the hotfix if you are experiencing the problem addressed by the hotfix. Otherwise, wait for the next release. -- Eric Niebler BoostPro Computing http://www.boostpro.com
On Fri, Aug 29, 2008 at 1:36 PM, Eric Niebler <eric@boostpro.com> wrote:
Michael Marcin wrote:
If the fixes are not critical enough to justify making a point release than they should wait until the next release.
So you're against hotfixes. <shrug> I would say, take the hotfix if you are experiencing the problem addressed by the hotfix. Otherwise, wait for the next release.
-- Eric Niebler BoostPro Computing http://www.boostpro.com
For some of us the answer is not <shrug>. Are hotfixes really the way forward? Not to pick on filesystem, threads or xpressive, but hotfixes are a bit difficult to manage in a coporate environment. It's hard enough to get boost accepted/updated without having to defend against people who argue that it's too risky to use boost due to "inadequate quality control" e.g. "boost 1.35.0 didn't work out of the box (windows thread bugs, filesystem compilation errors, etc.), boost 1.36.0 doesn't work out of the box, and there are no dot-releases planned". It really helps if there is a perception of stable, high quality, official, numbered releases. - Mat
Mat Marcus wrote:
On Fri, Aug 29, 2008 at 1:36 PM, Eric Niebler <eric@boostpro.com> wrote:
Michael Marcin wrote:
If the fixes are not critical enough to justify making a point release than they should wait until the next release. So you're against hotfixes. <shrug> I would say, take the hotfix if you are experiencing the problem addressed by the hotfix. Otherwise, wait for the next release.
-- Eric Niebler BoostPro Computing http://www.boostpro.com
For some of us the answer is not <shrug>. Are hotfixes really the way forward? Not to pick on filesystem, threads or xpressive, but hotfixes are a bit difficult to manage in a coporate environment. It's hard enough to get boost accepted/updated without having to defend against people who argue that it's too risky to use boost due to "inadequate quality control" e.g. "boost 1.35.0 didn't work out of the box (windows thread bugs, filesystem compilation errors, etc.), boost 1.36.0 doesn't work out of the box, and there are no dot-releases planned". It really helps if there is a perception of stable, high quality, official, numbered releases.
Sure, corporate environments often prefer to pretend software has no bugs, and thus rarely needs to be updated. I've got one customer who refuses to upgrade a ten+ year old C++ compiler because the vendor has come out with new releases every few years and management views that as a sign of great instability. Sigh. We took a straw-poll at BoostCon. Quarterly Boost releases were clearly the sweet spot for those present. There have been a number of posting to this list recently from folks who would like point releases in between the regular quarterly releases. We aren't going to do that, so making patches available is an experimental alternative. That's a lot more user friendly that asking people who want fixes to fool with Subversion, which may not be familiar to everyone. --Beman
Personally, I have no problems with hotfixes, but for those who prefer point releases, how about this: When a given version of Boost is at the end of its development lifecycle (i.e., when a new version of Boost is ready for release), take all the hotfixes for that version and package them into a point release, then release the point release and the new version at the same time. E.g., when Boost 1.37.0 is done, create a 1.36.1 out of all the available 1.36.0 hotfixes. This shouldn't add a significant resource burden, as the 1.36.1 package should only need a single test run (as opposed to the daily tests the new version would require) -- it's not being actively updated, should have no/minimal interface changes from the base version, and the changeset(s) making up a given hotfix have already received prior testing on trunk. To clarify, I'm advocating that individual hotfixes do not receive any automated testing, other than on trunk, as is currently done; only the point release resulting from all the hotfix changesets would need testing. The one "drawback" that I can think of is that Boost developers as a whole (i.e., more than just Beman and Eric ;-) would need to track/categorize changesets as hotfixes, so it could take a while to get enough momentum going to make it realistic/useful. Just my 2¢.
Mat Marcus wrote:
On Fri, Aug 29, 2008 at 1:36 PM, Eric Niebler <eric@boostpro.com> wrote:
Michael Marcin wrote:
If the fixes are not critical enough to justify making a point release than they should wait until the next release. So you're against hotfixes. <shrug> I would say, take the hotfix if you are experiencing the problem addressed by the hotfix. Otherwise, wait for the next release.
For some of us the answer is not <shrug>.
That wasn't my answer. See above.
Are hotfixes really the way forward? Not to pick on filesystem, threads or xpressive, but hotfixes are a bit difficult to manage in a coporate environment. It's hard enough to get boost accepted/updated without having to defend against people who argue that it's too risky to use boost due to "inadequate quality control" e.g. "boost 1.35.0 didn't work out of the box (windows thread bugs, filesystem compilation errors, etc.), boost 1.36.0 doesn't work out of the box
1.36.0 works out of the box. But I get your point.
, and there are no dot-releases planned". It really helps if there is a perception of stable, high quality, official, numbered releases.
Understood. You want point releases. We don't have the resources right now. We are busy flushing the bugs out of a new release process that should give us quarterly releases. This is in response to feedback such as yours. Beman has said on this list that the issue of point releases will be reconsidered once we are meeting our quarterly release schedule. In the mean time, corporate users of Boost have a few options: (1) ignore hotfixes, (2) pay for support, (3) consider donating the testing resources we would need to produce point releases. In the future, I could imagine staggered releases ... something like a 3 month full release cycle, followed by 1 or 2 months to put out a point release. With extra resources, these two could happen in parallel, of course. -- Eric Niebler BoostPro Computing http://www.boostpro.com
Michael Marcin wrote:
If the fixes are not critical enough to justify making a point release than they should wait until the next release.
So you're against hotfixes. <shrug> I would say, take the hotfix if you are experiencing the problem addressed by the hotfix. Otherwise, wait for the next release.
So long as the effort used to release the hotfixes doesn't take away from the effort used for proper releases. I don't spend the time with boost required to hunt around to make sure I have the right fixes (I use boost because it is convenient); I'd really like to see an x.xx.1 release for all boost versions, even if there was only a single bug is some unused corner of the library. ****************************************************************************** "This message and any attachments are solely for the intended recipient and may contain confidential and privileged information. If you are not the intended recipient, any disclosure, copying, use, or distribution of the information included in this message and any attachments is prohibited. If you have received this communication in error, please notify us by reply e-mail and immediately and permanently delete this message and any attachments. Thank you." Interactive Transaction Solutions Ltd (2473364 England) Registered Office: Systems House, Station Approach Emsworth PO10 7PW ********************************************************************** Ce message �lectronique contient des informations confidentielles � l'usage unique des destinataires indiqu�s, personnes physiques ou morales. Si vous n'�tes pas le destinataire voulu, toute divulgation, copie, ou diffusion ou toute autre utilisation de ces informations, est interdite. Si vous avez re�u ce message �lectronique par erreur, nous vous remercions d'en avertir son exp�diteur imm�diatement par email et de d�truire ce message ainsi que les �l�ments attach�s. Interactive transaction Solutions SAS- France (RCS Pontoise : 489 397 877) Si�ge social : Parc Saint Christophe, 10, Avenue de l�Entreprise 95865 Cergy-Pontoise Cedex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
Michael Marcin wrote:
Beman Dawes wrote:
Hotfix patches are available to fix Boost.Filesystem and Boost.Xpressive [1.36.0] problems. See https://svn.boost.org/trac/boost/wiki/ReleasePractices/HotFixes
Providing hotfix patches is something new and experimental for Boost. Please let us know if you find the patches useful or have other comments.
Are these libraries usable without these hotfixes or should they be considered required?
As far as Boost.Filesystem goes, it is perfectly usable. The fixes are primarily concerned with deprecated names. They only would be considered required if so much existing user code failed to compile that it is easier to apply the fixes than update the existing user code.
At my company we use Boost directly and use libraries that depend on Boost. We push those developers to upgrade their libraries when a new version of Boost is released and we realize that it is a burden on them and us to make the switch to the new versions.
In that sort of environment it is often best to stick with a particular version of Boost and other libraries until you reach a point in internal development cycles that it is convenient to change over to the newest versions of the libraries.
Generally this means there is a lag between release and adoption as we cannot move forward with a new version of Boost until all the third party libraries that we interface with upgrade their libraries to the new version of Boost.
Understood. That's quite a common scenario in mid-size and larger shops.
In my opinion this makes hotfixes worse than useless for us. We might not be able to upgrade to Boost+libraries that use Boost. For instance if library A upgrades to 1.36 plain and library B upgrades to 1.36 plus all or some of the hotfixes. If this compatibility problem occurs and the libraries also provide critical fixes to their own library then I believe we are stuck and must either drop the library, drop boost, or wait for everything to resynchronize.
I may be overreacting but this seems very dangerous to me.
Depends. In the kind of synchronized environment you are talking about, version upgrades do have to be managed carefully. OTOH, independent developers and other small and agile organizations may prefer to have the latest fixes, particularly if they are being impacted by the bugs being fixed.
If there are critical fixes I'd much rather have a point release which we can easily identify to the third party library providers. If the fixes are not critical enough to justify making a point release than they should wait until the next release.
That makes sense in the environment you describe. HTH, --Beman
My 2 cents: 1. Point releases should never break interfaces ever, they should be for those organizations who need minor bugs fixed but don't have the spare cycles to rework their code due to interface changes. Think of all the test cases, etc that might need rewritten and even the test case code themselves might depend on the same library. Interface changes will reduce the number parties able to even consider taking the release. 2. Organizations like those with the 10 year old tool chains are not going to consume any releases after their already accepted dependancies regardless, due to whatever risks they have whether contrived or not. 3. Major releases will generally be comsumed by organixations starting new projects or major revisions of existing projects because this is when they can afford the risks and at the same time will have spare cycles. 4. Developers or organizations agile enough to take point releases or patches will have no problem using a vcs system to fetch those changes or to apply patches, they should be experts at this. They will probably also be taking all major releases too. 5. My opinion is that for any shop with multiple layers of dependancies, as described below, they should choose a version of the dependancy and upgrade across the site only with major revisions if deemed necessary. For general software development, they will be very few compelling reasons that will warrant a library upgrade. The last thing one would desire is to bore developers with tasks they generally dislike ( library upgrades being one of those ). Josh phillips Virus analyst Microsoft Sent from my Verizon Wireless BlackBerry -----Original Message----- From: Beman Dawes <bdawes@acm.org> Date: Fri, 29 Aug 2008 18:01:15 To: <boost-users@lists.boost.org> Cc: <boost@lists.boost.org> Subject: Re: [Boost-users] [filesystem][xpressive] Hotfix patches available for 1.36.0 Michael Marcin wrote:
Beman Dawes wrote:
Hotfix patches are available to fix Boost.Filesystem and Boost.Xpressive [1.36.0] problems. See https://svn.boost.org/trac/boost/wiki/ReleasePractices/HotFixes
Providing hotfix patches is something new and experimental for Boost. Please let us know if you find the patches useful or have other comments.
Are these libraries usable without these hotfixes or should they be considered required?
As far as Boost.Filesystem goes, it is perfectly usable. The fixes are primarily concerned with deprecated names. They only would be considered required if so much existing user code failed to compile that it is easier to apply the fixes than update the existing user code.
At my company we use Boost directly and use libraries that depend on Boost. We push those developers to upgrade their libraries when a new version of Boost is released and we realize that it is a burden on them and us to make the switch to the new versions.
In that sort of environment it is often best to stick with a particular version of Boost and other libraries until you reach a point in internal development cycles that it is convenient to change over to the newest versions of the libraries.
Generally this means there is a lag between release and adoption as we cannot move forward with a new version of Boost until all the third party libraries that we interface with upgrade their libraries to the new version of Boost.
Understood. That's quite a common scenario in mid-size and larger shops.
In my opinion this makes hotfixes worse than useless for us. We might not be able to upgrade to Boost+libraries that use Boost. For instance if library A upgrades to 1.36 plain and library B upgrades to 1.36 plus all or some of the hotfixes. If this compatibility problem occurs and the libraries also provide critical fixes to their own library then I believe we are stuck and must either drop the library, drop boost, or wait for everything to resynchronize.
I may be overreacting but this seems very dangerous to me.
Depends. In the kind of synchronized environment you are talking about, version upgrades do have to be managed carefully. OTOH, independent developers and other small and agile organizations may prefer to have the latest fixes, particularly if they are being impacted by the bugs being fixed.
If there are critical fixes I'd much rather have a point release which we can easily identify to the third party library providers. If the fixes are not critical enough to justify making a point release than they should wait until the next release.
That makes sense in the environment you describe. HTH, --Beman _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Hi raindog@macrohmasheen.com
My 2 cents:
Argh... please do not top-post... and if you do then at least do not make your part of the mail long AND not place any quoting characters in front of lines belonging to the original post you are replying to. Reading that mail was a very unpleasant experience. Many thanks. Best regards, Jurko Gospodnetić
I have just downloaded and applied one of the patches. I think the patches are very useful and convenient. (I work for a tiny software company, three full-time employees, one developer (me) and two sales people.) --Johan '
participants (9)
-
Adam Merz -
Beman Dawes -
Eric Niebler -
Johan Råde -
Jurko Gospodnetić -
Mat Marcus -
Michael Marcin -
Patrick Loney -
raindog＠macrohmasheen.com