 |
Forums |
Admin  Start New Thread
By: Ikkei
 RE: Version numbers [ reply ]
2004-09-10 23:24
|
>> Aversa::Application::VERSION_STRING
> Excellent, I think that's much easier to track. Good stuff.
Seem, optparse prepare --version option, already.
it goes to look top class's variable "Version",
and "VERSION" (If not define It shows ruby's version)
In aversa.rb, now
opt = app.define_options( OptParse.new )
app.main( *opt.parse(*argv) )
sub-modules def define_options method.
app.define_options append option rules to optparse
and apply it. it is crossing, hard to follow.
I am still thinking generate optparse rules, though
I hope the codes won't be messy ^^;;
|
By: Tom Copeland
RE: Version numbers [ reply ]
2004-09-10 14:24
|
> all script files can have
> revision numbers by RCS tag
Cool, that sounds good.
> Aversa::Application::VERSION_STRING
Excellent, I think that's much easier to track. Good stuff.
Yours,
Tom
|
By: Ikkei
RE: Version numbers [ reply ]
2004-09-10 01:10
|
I think one version number for --version option.
and all script files can have revision numbers
by RCS tag. $Id$ or $rivision$ update auto at commit time.
Now I changed
./bin/aversa.rb Aversa::Application::VERSION_STRING only have the version info.
# If shell script needs the version number,
AVERSA_VERSION=`ruby -raversa -e "puts Aversa::Application::VERSION_STRING"`
|
By: Tom Copeland
Version numbers [ reply ]
2004-09-09 21:11
|
Hi Ikkei -
Do you think we should have a different version number for each module? Or just one version number for the whole thing?
I am thinking that perhaps with so many version numbers we will begin to forget to update them as we change things. But I am not sure about this; either way it probably OK.
Yours,
Tom
|
|
|
