Some of you may have already noticed: As the v1.5 RM, I took the executive decision this morning to bump up the tarball versions of the GNU Autotools on the v1.5 branch this morning. Some of you may remember that we have a policy of not changing autotools versions in a release series unless we need to.
So I thought I'd explain my rationale: 1. I've been mulling about this issue for about a week, and talked with Brian about it. The conclusion we came to was that we should amend our current policy: upgrade the Autotools tuple when necessary/relevant during feature series, but keep the tuple steady during stable release series. So -- why upgrade for v1.5.5? 2. We're preparing for v1.6, which will assumedly have a very long shelf life. 3. We've already had user reports of compiler issues due to older Libtool versions in Open MPI v1.4 and v1.5 releases. 4. Specifically: before today, we were using Libtool 2.2.6b for the v1.5 series. Libtool 2.2.6b is *ancient*! Compilers have changed a *lot* since the 2.2.6b snapshot that we use (remember: 2.2.6b was not a formal Libtool release). 5. These problems will only get worse as time goes on, so it seemed to make sense to refresh to the latest versions of everything before we hit v1.6, thereby enabling the v1.6 series to have as long a shelf life as possible. 6. It didn't make sense to upgrade the v1.5 branch without upgrading the trunk, so I updated both of them. What this means is that nightly and release tarballs built on these SVN branches will use the new autotools. 7. This does *NOT* mean that developers must upgrade their autotools immediately. It does mean that we'll likely stop using/testing older autotools versions with trunk/v1.5 over time, and therefore they may eventually stop working (i.e., forcing developer autotools upgrades at that time). -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
