Modules and version determination

ruby-talk
1

Hi all,

I’m curious as to what you all think about an internal ‘version()’ method
for published modules. I’ve seen a few threads out on Google, but no
definitive consensus on the subject.

In other words, should we always put a “version” method (or VERSION, or
version, or whatever) within our modules as a class method? If so, what
syntax do people prefer?

Keep in mind that this could be used for raa.next (or will rubygems take
care of that?).

The forum is now open. :slight_smile:

Regards,

Dan

2

I think I brought this up on IRC, suggesting that a published module
should have @@VERSION_MAJOR, @@VERSION_MINOR and @@VERSION_PATCHLEVEL
defined.

Maybe we just define a ModuleVersion class to make this easier.
Have things like:

@@version = ModuleVersion.new(3, 1, 4) # Version 3.1.4

@@version.to_s # => “3.1.4”
@@version.to_a # => [3, 1, 4]
@@version.major # => 3
@@version.minor # => 1
@@version.patchlevel # => 4

Just a thought,

– Dossy

···

On 2002.06.12, Mr. Sunblade djberge@qwest.com wrote:

Hi all,

I’m curious as to what you all think about an internal ‘version()’ method
for published modules. I’ve seen a few threads out on Google, but no
definitive consensus on the subject.

In other words, should we always put a “version” method (or VERSION, or
version, or whatever) within our modules as a class method? If so, what
syntax do people prefer?

Keep in mind that this could be used for raa.next (or will rubygems take
care of that?).

The forum is now open. :slight_smile:

–
Dossy Shiobara mail: dossy@panoptic.com
Panoptic Computer Network web: http://www.panoptic.com/
“He realized the fastest way to change is to laugh at your own
folly – then you can let go and quickly move on.” (p. 70)

3

Hi all,

I’m curious as to what you all think about an internal ‘version()’
method for published modules. I’ve seen a few threads out on Google,
but no definitive consensus on the subject.

In other words, should we always put a “version” method (or VERSION, or
version, or whatever) within our modules as a class method? If so,
what syntax do people prefer?

I’ve got a module that I wrote called Meta that is used to define metadata
such as version numbers. From it’s minimal documentation:

··· 
                  FILE NAME: $RCSfile: Meta.rb,v $

REVISION: $Revision: 1.5 $
AUTHOR: $Author: khaines $
DATE MODIFIED: $Date: 2002/01/19 08:09:13 $

                               PURPOSE:

Provides a set of mixins that let one set version, modification date,
and other similar sorts of module/class information in a way that is
human readable and also software queryable.

                               EXAMPLE:

Class Foo
require “Meta”
include Meta

version .13
author ‘Jack Black’
modification_date ‘17 Jan 2002’
state ‘stable’
about <<-EABOUT
Provides mixin methods that let one specify versioning and
other descriptive information in a human readable and code
queryable manner.
EABOUT
history <<-EHISTORY
# $Log: Meta.rb,v $
# Revision 1.5 2002/01/19 08:09:13 khaines
# Removed the module declaration. That’s not really what this is.
#
# Revision 1.4 2002/01/17 07:17:34 khaines
# Fixed a small typo.
#
# Revision 1.3 2002/01/17 05:41:00 khaines
# Added the first swing at inlined documentation to the module.
#
# Revision 1.2 2002/01/14 07:54:47 khaines
# Added some comments.
#
EHISTORY

The code underlying it can certainly be improved. It was one of my
early forays into Ruby. It provides the following facilities:

version()
Takes a String that contains a version number. If no argument, returns
the last set version #.

version ‘1.23.07b’
myver = version() #myver contains “1.23.07b”

cvsVersion()
Takes a version string as delivered by the Revision tag of CVS (RCS)
and trims of the extraneous information, leaving just the version number.

cvsVersion '$Revision: 1.5 $
myver = version() #myver contains “1.5”

modification_date()
Sets or returns the last modification date of the module or class.
Uses ParseDate::parsedate to make sense of any value passed to it, and
returns a string containing the date, asctime() formatted.

modification_date ‘17 Jul 2003 16:41:39’
mod_date = modification_date();

author()
Takes a string containing the author’s name. If called without an arg,
returns the last set author’s name.

author ‘Jack Black’
myauthor = author() #Contains “Jack Black”

history()
Takes a string describing the class or module history. If called without
and arg, returns the history as a string.

state()
Sets or gets a string giving a simple description of the state of the
class or module.

about()
Sets or gets a string describing what the class or module is all about.

The idea was so that I could make my library of code software indexable
and queryable so that I could provide, for example, a web app that let one
browse high level information about the code corpus, then drill down tothe documentation within the file for more information.

If anyone is interested, I can put this module where you can download it.

Kirk Haines

4

Hello,

I am interested to have a look at it. Thanks.

Jean-Hugues

···

At 05:41 12/06/2002 +0900, you wrote:

Hi all,

I’m curious as to what you all think about an internal ‘version()’
method for published modules. I’ve seen a few threads out on Google,
but no definitive consensus on the subject.

In other words, should we always put a “version” method (or VERSION, or
version, or whatever) within our modules as a class method? If so,
what syntax do people prefer?

I’ve got a module that I wrote called Meta that is used to define metadata
such as version numbers. From it’s minimal documentation:

                  FILE NAME: $RCSfile: Meta.rb,v $

REVISION: $Revision: 1.5 $
AUTHOR: $Author: khaines $
DATE MODIFIED: $Date: 2002/01/19 08:09:13 $

                               PURPOSE:

Provides a set of mixins that let one set version, modification date,
and other similar sorts of module/class information in a way that is
human readable and also software queryable.

                               EXAMPLE:

Class Foo
require “Meta”
include Meta

version .13
author ‘Jack Black’
modification_date ‘17 Jan 2002’
state ‘stable’
about <<-EABOUT
Provides mixin methods that let one specify versioning and
other descriptive information in a human readable and code
queryable manner.
EABOUT
history <<-EHISTORY
# $Log: Meta.rb,v $
# Revision 1.5 2002/01/19 08:09:13 khaines
# Removed the module declaration. That’s not really what this is.
#
# Revision 1.4 2002/01/17 07:17:34 khaines
# Fixed a small typo.
#
# Revision 1.3 2002/01/17 05:41:00 khaines
# Added the first swing at inlined documentation to the module.
#
# Revision 1.2 2002/01/14 07:54:47 khaines
# Added some comments.
#
EHISTORY

The code underlying it can certainly be improved. It was one of my
early forays into Ruby. It provides the following facilities:

version()
Takes a String that contains a version number. If no argument, returns
the last set version #.

version ‘1.23.07b’
myver = version() #myver contains “1.23.07b”

cvsVersion()
Takes a version string as delivered by the Revision tag of CVS (RCS)
and trims of the extraneous information, leaving just the version number.

cvsVersion '$Revision: 1.5 $
myver = version() #myver contains “1.5”

modification_date()
Sets or returns the last modification date of the module or class.
Uses ParseDate::parsedate to make sense of any value passed to it, and
returns a string containing the date, asctime() formatted.

modification_date ‘17 Jul 2003 16:41:39’
mod_date = modification_date();

author()
Takes a string containing the author’s name. If called without an arg,
returns the last set author’s name.

author ‘Jack Black’
myauthor = author() #Contains “Jack Black”

history()
Takes a string describing the class or module history. If called without
and arg, returns the history as a string.

state()
Sets or gets a string giving a simple description of the state of the
class or module.

about()
Sets or gets a string describing what the class or module is all about.

The idea was so that I could make my library of code software indexable
and queryable so that I could provide, for example, a web app that let one
browse high level information about the code corpus, then drill down tothe
documentation within the file for more information.

If anyone is interested, I can put this module where you can download it.

Kirk Haines

Web: @jhr is virteal, virtually real
Phone: +33 (0) 4 92 27 74 17

5

I think I brought this up on IRC, suggesting that a published module
should have @@VERSION_MAJOR, @@VERSION_MINOR and @@VERSION_PATCHLEVEL
defined.

Ruby uses MAJOR, MINOR, and TEENY. It would be nice to be consistent.

Maybe we just define a ModuleVersion class to make this easier.
Have things like:

@@version = ModuleVersion.new(3, 1, 4) # Version 3.1.4

@@version.to_s # => “3.1.4”
@@version.to_a # => [3, 1, 4]
@@version.major # => 3
@@version.minor # => 1
@@version.patchlevel # => 4

I wrote a class called RubyVersion that I use to check to see if I have
the right version of Ruby:

if RubyVersion.current >= “1.7.1” then
# We have the technology
else
# Must fall back on the old skool way
end

It can also be used for modules, like you describe:

@@version = RubyVersion.new(3, 1, 4)

but it’s not complete. I definitely like your idea.

Paul

···

On Wed, Jun 12, 2002 at 04:45:37AM +0900, Dossy wrote:

6

Kirk Haines wrote:

If anyone is interested, I can put this module where you can download it.

Kirk Haines

I would be interested.

7

slap. Version numbers are not floats.

0.13 is Major(Zero), Minor(Thirteen), not Zero point One Three.

I do think something like this would probably be worthwhile though;
being able to do:

raise 'Version mismatch' if Some::Module::VERSION < '1.2.3'

Would doubtless be useful for some. I’d want to see it in the standard
library, though; otherwise we’ll just end up with umpteen different
versioning and metadata schemes, all slightly different.

···

version .13

–
Thomas ‘Freaky’ Hurst - freaky@aagh.net - http://www.aagh.net/

The problem with people who have no vices is that generally you can
be pretty sure they’re going to have some pretty annoying virtues.
– Elizabeth Taylor

8

Ruby uses MAJOR, MINOR, and TEENY. It would be nice to be consistent.

Ah, didn’t know that.

I wrote a class called RubyVersion that I use to check to see if I have
the right version of Ruby:
[…]
It can also be used for modules, like you describe:
[…]
but it’s not complete. I definitely like your idea.

Someone else posted that they had code that could be used as
a Mixin to let you attach versioning information to a class, I
think that’s the better way of doing this …

But, maybe I’m wrong. It’s good to know that it can be done
either way …

– Dossy

···

On 2002.06.13, Paul Brannan pbrannan@atdesk.com wrote:

–
Dossy Shiobara mail: dossy@panoptic.com
Panoptic Computer Network web: http://www.panoptic.com/
“He realized the fastest way to change is to laugh at your own
folly – then you can let go and quickly move on.” (p. 70)

9

The two ideas are somewhat orthogonal. RubyVersion was really just a
way of representing the version, so it can easily be compared to other
versions. Kirk’s mixin attaches the version to the module, and could
easily store the version as a Version object instead of as a string or a
float.

Paul

···

On Thu, Jun 13, 2002 at 02:22:08AM +0900, Dossy wrote:

Someone else posted that they had code that could be used as
a Mixin to let you attach versioning information to a class, I
think that’s the better way of doing this …

But, maybe I’m wrong. It’s good to know that it can be done
either way …

10

The two ideas are somewhat orthogonal. RubyVersion was really just a
way of representing the version, so it can easily be compared to other
versions. Kirk’s mixin attaches the version to the module, and could
easily store the version as a Version object instead of as a string or
a float.

Yes, quite easily. Right now it accept the version as a string, on the
assumption that there are few assumptions about version numbers. I could
easily change it to store that version, as you say, in a Version object.

Kirk Haines