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