Re: [Gramps-devel] version string?

[Stephen G. <ste...@op...>]

On 26/04/2010 2:43 AM, Stéphane Charette wrote:
> 2010/4/25 Doug Blank<dou...@gm...>:
>    
>> 2010/4/25 Stéphane Charette<ste...@gm...>:
>>      
>>> We used to have the version string in configure.in, but now I see from
>>> a checkin by Doug that we also have the version string in const.py.in.
>>>
>>> Is this new...or have I always done it wrong in the past?  I don't
>>> recall having to update 2 different files with the version information
>>> before.  If this is new -- should we not have 1 source file with the
>>> version string?  At the very least, maybe 1 original one, and the
>>> other generated from the first?
>>>        
>> The one in const.py.in is a fallback for those that don't use config.
>> This is something I added a couple of months back so that people just
>> need to copy const.py.in to const.py and gramps is ready to use (eg,
>> people on Windows).
>>
>> Ideally, I think the solution is to use distutils rather than the
>> complexity of config. But that will take some effort.
>>      
> What is the other used for?  Can we get rid of that one then?  It just
> seems weird to have 3 instances of the version string to modify, 1 in
> configure.in and 2 in const.py.in.
>
> On the other hand, if everyone is OK with it like this, I'll just
> modify the wiki page on what to do when we release, and wont worry
> about it anymore.
>
> Stéphane
>    

I think the only people the fall back will be used for is someone 
running Gramps from within SVN (both Linux + Windows).
Linux if they forget to run  ./autogen.sh (and don't have an old 
const.py lying around)
Windows because they don't have a script to run. (easily fixed, can make 
a python script for them to run)

Anyone with an installed version of Gramps for Windows doesn't have to 
worry about such things. The version number is already taken care of.

So from my point of view, the fallback is just for developer convenience.

To that end I can't help but think the version number in const.py.in is 
a mis-representation of the true version number. On Linux after running 
/autogen.sh a developers SVN version  number will be of the form 
gramps-3.3.0-SVN1234.  Currently the 'fallback' version number 
represented in const.py.in is 3.3.0 and could be confused with a future 
release version.

Previously (before fallback) when I copied const.py.in to const.py SVN 
Gramps worked just fine, it just didn't have a version number, but 
@VERSIONSTRING@ instead.

My vote would be to leave the version number in configure.in and create 
a script for windows SVN users to generate a valid const.py, that will 
mimic the version numbers that Linux users would get if they run 
./autogen.sh

Until Gramps migrates away from using configure.in, I think it only wise 
to leave the version number in configure.in

Just my 2 cents worth.
- Steve