On 30 Mar 2013, at 14:27, Fotis Georgatos wrote: > > Hi Ken, > > On Mar 30, 2013, at 2:13 PM, Kenneth Hoste wrote: >> If you're actively testing the EasyBuild release candidate, please update to >> the latest v1.3.x and v1.3.0.x branches of easybuild-framework and >> easybuild-easyconfigs, respectively, >> to install the 2nd release candidate for EasyBuild v1.3.0, i.e. v1.3.0rc2. > > this is not critical, just fyi, in my modulefile I had to type: > > set EB_framework > $root/lib/python2.6/site-packages/easybuild_framework-$ebver-py2.6.egg > set EB_easyblocks > $root/lib/python2.6/site-packages/easybuild_easyblocks-1.3.0rc1-py2.6.egg > set EB_easyconfigs > $root/lib/python2.6/site-packages/easybuild_easyconfigs-1.3.0.0rc2-py2.6.egg > > 1) is it normal that EB_easyblocks is at 1.3.0rc1? > ie. check if the correct thing is delivered by > http://github.com/hpcugent/easybuild-easyblocks/archive/v1.3.x.tar.gz
Yes, no bugs were found in easybuild-easyblocks, so the first release candidate should work. > > 2) The numbering scheme of easyconfigs is a PITA... can we improve on it a > bit? > I have a growing belief that with monthly & bugfix releases, it is not all > that useful. Currently, it seems like it doesn't make much sense, but this may change in the future. The easyconfigs version is the easyblocks version it requires plus an extra digit for bugfix releases, see also https://github.com/hpcugent/easybuild/wiki/Packaging-and-versioning . We're not going to change it for v1.3.0, but we can discuss it for future releases. In my mind, we'd better look at shipping a single tarball for future releases, while keeping the framework/easyblocks/easyconfigs repos separate. Should be a lot less headaches, and no need for (visible) funky version numbers of different packages. > > ps. some cool news about to arrive in my next email. Can't wait... ;-) K.
