[Rivet] aida2root

[Andy Buckley]

Ben Waugh wrote:
> Hi Andy,
> 
> On 07/10/09 11:01, Andy Buckley wrote:
>> Ben Waugh wrote:
>>> Hi Andy, All,
>>>
>>> Looks like this fix, and the clearer warning message, has got lost
>>> somewhere along the way, since the tagged release rivet-1.1.3 has
>>> os.has_key("ROOTSYS")
>>> instead of
>>> if os.environ.has_key("ROOTSYS")
>>> in aida2root.
>>>
>>> Can it please be fixed again in the next tagged version?
>>
>> Bizarre! I've no idea how that managed to not make it into the release.
>> It'll definitely be correct in the next release.
> 
> D'oh. Of course this release was tagged before the fix. I was confused 
> by the fact that version 1.1.3 has been modified after it was tagged, 
> but presumably only the build stuff rather than the source code itself.

That should be right: the modification was a fix to the GSL detection, 
in order to let James install Rivet 1.1.3 in Genser for the 
pathologically silly SLC5 platform (the "scientific" OS without GSL!)

> Now I'm even more confused though. Probably due to an incorrect blood 
> caffeine level or maybe BSE, but at the risk of embarrassment...
> 
> It seems that the version of "aida2root" in Svn as 
> tags/rivet-1.1.3/bin/aida2root is completely different from the version 
> in the tarball Rivet-1.1.3.tar.gz that is downloaded by the bootstrap 
> script. The version in the tarball looks familiar and has the (albeit 
> incorrect) check on $ROOTSYS, but the version in Svn does not.

Agreed. This is what I don't understand... it looks like the svn version 
is somehow a regression. Hope there aren't any more of those.

> Is this also related to changes in the code since the tag was created? 
> Should we perhaps add a patch number to the end of the Rivet release 
> number so we know exactly which version of the code (and build scripts) 
> we are really using?

I was avoiding that since the re-tag change should have been small and I 
didn't get a chance to rebuild the 1.1.3 tarball. Now that I see this 
problem, I'm even less keen to make a tarball from this tag!

> Anyway, in this case the problem is fixed in the trunk.

Yes. As always, I think the trunk version is so much better than the 
last release that we should concentrate on getting release 1.2.0 out. 
However, if anyone wants to chase this up and make a new tarball, please do!

Moving to a more sensible version increment from 1.2.0 onwards also 
leaves that last digit for marking genuine patches, rather than adding 
ad hoc weird extensions like Atlas does (since when has "15.3.X.Y" 
actually been a real version code?!?)

Sorry for the confusion ;)
Andy