Modules and version determination 
Author Message
 Modules and version determination

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. :)

Regards,

Dan



Sun, 28 Nov 2004 03:03:29 GMT  
 Modules and version determination

Quote:
> 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. :)

I think I brought this up on IRC, suggesting that a published module

defined.

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







Just a thought,

-- Dossy

--

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)



Sun, 28 Nov 2004 03:50:15 GMT  
 Modules and version determination

Quote:
> 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



Sun, 28 Nov 2004 04:47:31 GMT  
 Modules and version determination
Hello,

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

Jean-Hugues


Quote:
> > 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:  http://hdl.handle.net/1030.37/1.1
Phone: +33 (0) 4 92 27 74 17


Sun, 28 Nov 2004 15:54:52 GMT  
 Modules and version determination

Quote:

> I think I brought this up on IRC, suggesting that a published module

> defined.

Ruby uses MAJOR, MINOR, and {*filter*}Y.  It would be nice to be consistent.

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








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:


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

Paul



Mon, 29 Nov 2004 01:12:08 GMT  
 Modules and version determination

Quote:

> Ruby uses MAJOR, MINOR, and {*filter*}Y.  It would be nice to be consistent.

Ah, didn't know that.

Quote:
> 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

--

Panoptic Computer Network             web: http://www.*-*-*.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)



Mon, 29 Nov 2004 01:32:54 GMT  
 Modules and version determination

Quote:

> 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 ...

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



Mon, 29 Nov 2004 03:17:07 GMT  
 Modules and version determination

Quote:

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

> Kirk Haines

I would be interested.


Mon, 29 Nov 2004 03:38:37 GMT  
 Modules and version determination

Quote:
> 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



Mon, 29 Nov 2004 04:31:27 GMT  
 Modules and version determination

Quote:
>   version .13

*slap*.  Version numbers are *not* floats.

0.13 is Major(Zero), Minor(Thir{*filter*}), 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 ump{*filter*} different
versioning and metadata schemes, all slightly different.

--

-
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



Mon, 29 Nov 2004 05:29:09 GMT  
 Modules and version determination

Quote:
> -----Original Message-----

> Sent: Wednesday, June 12, 2002 3:25 PM

> Subject: Re: Modules and version determination

> > 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

Kirk, it sounds like you've thought this out a bit.  Any chance of
publishing something?  It sounds like a good idea.  Once you have something
out there, it's a small step to write a script that generates some stub
documentation and methods automatically when you want to create a new
module, ala Perl's h2xs (ok, slightly different, but hopefully you get the
point).

Anyone care to second my nomination? :-)

Regards,

Dan



Mon, 29 Nov 2004 20:45:43 GMT  
 Modules and version determination

Quote:
> Kirk, it sounds like you've thought this out a bit.  Any chance of
> publishing something?  It sounds like a good idea.  Once you have something
> out there, it's a small step to write a script that generates some stub
> documentation and methods automatically when you want to create a new
> module, ala Perl's h2xs (ok, slightly different, but hopefully you get the
> point).

> Anyone care to second my nomination? :-)

Another thing that is important to track is module dependencies.
Say, if I write a module Foo that depends on REXML, I should be
able to specify that in the module metadata as well.

Perhaps we can start gathering some requirements on the wiki
and once there's consensus, put together a simple implementation.
Then, if it's worthy, it'll take hold and people will use it.
Otherwise, it'll get abandoned and that'll tell us something
about it's necessity.

I personally would love to do:

  ruby -raa upgrade REXML-stable

and have it go out, check to see if there's a newer version of
REXML out, and install it for me.

-- Dossy

--

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)



Mon, 29 Nov 2004 21:58:52 GMT  
 Modules and version determination

Quote:
> Another thing that is important to track is module dependencies.
> Say, if I write a module Foo that depends on REXML, I should be
> able to specify that in the module metadata as well.

> Perhaps we can start gathering some requirements on the wiki
> and once there's consensus, put together a simple implementation.
> Then, if it's worthy, it'll take hold and people will use it.
> Otherwise, it'll get abandoned and that'll tell us something
> about it's necessity.

I'll volunteer to take my current module and mutate it to fit this
set of requirements.

Quote:
> I personally would love to do:

>  ruby -raa upgrade REXML-stable

That would be very cool, indeed.

Kirk Haines



Mon, 29 Nov 2004 23:01:52 GMT  
 Modules and version determination

Quote:
> -----Original Message-----

> Sent: Thursday, June 13, 2002 10:00 AM

> Subject: Re: Modules and version determination

> > Another thing that is important to track is module dependencies.
> > Say, if I write a module Foo that depends on REXML, I should be
> > able to specify that in the module metadata as well.

> > Perhaps we can start gathering some requirements on the wiki
> > and once there's consensus, put together a simple implementation.
> > Then, if it's worthy, it'll take hold and people will use it.
> > Otherwise, it'll get abandoned and that'll tell us something
> > about it's necessity.

> I'll volunteer to take my current module and mutate it to fit this
> set of requirements.

Hooray!  Thanks!

Please keep us posted. :)

Dan



Mon, 29 Nov 2004 23:59:25 GMT  
 Modules and version determination

Quote:

> Perhaps we can start gathering some requirements on the wiki
> and once there's consensus, put together a simple implementation.
> Then, if it's worthy, it'll take hold and people will use it.
> Otherwise, it'll get abandoned and that'll tell us something
> about it's necessity.

> I personally would love to do:

>   ruby -raa upgrade REXML-stable

> and have it go out, check to see if there's a newer version of
> REXML out, and install it for me.

You can already do the latter with rpkg/rapt:

    rapt install rdoc

It is checked if a newer version is available and it is installed
according to the user configuration (e.g. all the docs here, all the
tests there, all the binaries here...).  You can remove packages,
search them, query for description, version, maintainer address,
etc. as well.

Versioning information is supported, dependence handling not yet.
Also, there are only a dozen packages online.  The entire process of
packaging takes about 10 minutes and is explained in the tutorial,
uploads are welcome.

The whole thing is downloadable from
http://www.allruby.com/rpkg/rpkg-0.3.3.tar.gz, documentation is
English and Japanese (courtesy dellin).

Massimiliano



Tue, 30 Nov 2004 09:49:22 GMT  
 
 [ 19 post ]  Go to page: [1] [2]

 Relevant Pages 

1. TkTable version determination

2. Locale name determination

3. EOF determination

4. Network Concurrent User Determination

5. Date Determination

6. Linker determination at run-time

7. types, determination, seperate compilation and side effects

8. Frequency Determination

9. Day-Of-Week determination

10. ErrorDocument/CGI error code determination

11. Runtime object type determination/ runtime generic instantiation

12. XMS Memory size determination

 

 
Powered by phpBB® Forum Software