1. The VERSION file in arrayfields-3.1.0.tgz still reads 3.0.0.
2. Can you release as a gem? And to save you the trouble...
C:\temp\arrayfields>cat arrayfields.gemspec
require 'rubygems'
spec = Gem::Specification.new do |s|
s.name = 'arrayfields'
s.version = File.read("VERSION").strip
s.platform = Gem::Platform::RUBY
s.summary = "Allow keyword access to arrays"
s.files = %w{lib/arrayfields.rb}
s.require_path = 'lib'
s.autorequire = "arrayfields"
s.has_rdoc = true
s.test_suite_file = "test/arrayfields.rb"
s.author = "Ara T. Howard"
s.email = "ara.t.howard@noaa.gov"
s.homepage = "http://raa.ruby-lang.org/project/arrayfields"
end
if $0==__FILE__
Gem::Builder.new(spec).build
end
C:\temp\arrayfields>ruby arrayfields.gemspec
Successfully built RubyGem
Name: arrayfields
Version: 3.1.0
File: arrayfields-3.1.0.gem
C:\temp\arrayfields>gem --run-tests -i arrayfields-3.1.0.gem
Attempting local installation of 'arrayfields-3.1.0.gem'
Successfully installed arrayfields version 3.1.0
C:\temp\arrayfields>ruby -r arrayfields -e 'a = [42]; a.fields =
[:answer]; p a[:answer]'
42
<snip gem spec>
thanks alot mehr-
i'll try to get to this today - it's one of those things i've been meaning to
do (for all my stuff) but haven't been able to get to... i'm a little
concerned about how the gem versioning technique will play with mine, any
ideas on that?
cheers.
-a
···
On Wed, 30 Jun 2004, Mehr, Assaph (Assaph) wrote:
1. The VERSION file in arrayfields-3.1.0.tgz still reads 3.0.0.
2. Can you release as a gem? And to save you the trouble...
--
EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
PHONE :: 303.497.6469
A flower falls, even though we love it;
and a weed grows, even though we do not love it. --Dogen
===============================================================================
Yours has got stronger semantics than RubyGems' (which basically provides
the methods but sets no policy), so it will work just fine if users do
require_gem "arrayfields", ">=3.1", "<4.0"
although there's no support for the backwards compatibility indicator
(3rd digit).
(not 100% sure about the syntax however)
···
On Thu, Jul 01, 2004 at 12:12:52AM +0900, Ara.T.Howard wrote:
On Wed, 30 Jun 2004, Mehr, Assaph (Assaph) wrote:
>
>1. The VERSION file in arrayfields-3.1.0.tgz still reads 3.0.0.
>2. Can you release as a gem? And to save you the trouble...
<snip gem spec>
thanks alot mehr-
i'll try to get to this today - it's one of those things i've been meaning
to
do (for all my stuff) but haven't been able to get to... i'm a little
concerned about how the gem versioning technique will play with mine, any
ideas on that?
--
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com
If you want to travel around the world and be invited to speak at a lot
of different places, just write a Unix operating system.
-- Linus Torvalds
good enough - i'll make an effort to roll my package into a gem then...
gems seem pretty well thought out i must say. kudos to the developers.
cheers.
-a
···
On Thu, 1 Jul 2004, Mauricio [iso-8859-1] Fernández wrote:
Yours has got stronger semantics than RubyGems' (which basically provides
the methods but sets no policy), so it will work just fine if users do
require_gem "arrayfields", ">=3.1", "<4.0"
although there's no support for the backwards compatibility indicator
(3rd digit).
(not 100% sure about the syntax however)
--
EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
PHONE :: 303.497.6469
A flower falls, even though we love it;
and a weed grows, even though we do not love it. --Dogen
===============================================================================
Mauricio Fernández said:
Yours has got stronger semantics than RubyGems' (which basically provides
the methods but sets no policy), so it will work just fine if users do
require_gem "arrayfields", ">=3.1", "<4.0"
Or ...
require_gem "arrayfields", "~> 3.1"
You can think of the ~> operator as "approximately greater than/equal to".
It will allow any version from 3.1 upto (but not including) 4.0. The
theory is that changes in major version number break backwards
compatibility. I call this a pessimistic version request (you expect
things to break), where "> 3.1" is an optomistic version request (you hope
thinkgs won't break).
See http://rubygems.rubyforge.org/wiki/wiki.pl?UserGuide#operators for
details.
···
--
-- Jim Weirich jim@weirichhouse.org http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
so the gem versioning concept is similar to the libtool concept
interface.implementation.age
minus the age bit - and a change in interface is expected to break code
whereas a change in impl, in theory, should not?
-a
···
On Thu, 1 Jul 2004, Jim Weirich wrote:
Mauricio Fernández said:
Yours has got stronger semantics than RubyGems' (which basically provides
the methods but sets no policy), so it will work just fine if users do
require_gem "arrayfields", ">=3.1", "<4.0"
Or ...
require_gem "arrayfields", "~> 3.1"
You can think of the ~> operator as "approximately greater than/equal to".
It will allow any version from 3.1 upto (but not including) 4.0. The
theory is that changes in major version number break backwards
compatibility. I call this a pessimistic version request (you expect
things to break), where "> 3.1" is an optomistic version request (you hope
thinkgs won't break).
See http://rubygems.rubyforge.org/wiki/wiki.pl?UserGuide#operators for
details.
--
EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
PHONE :: 303.497.6469
A flower falls, even though we love it;
and a weed grows, even though we do not love it. --Dogen
===============================================================================
Ara.T.Howard said:
so the gem versioning concept is similar to the libtool concept
interface.implementation.age
minus the age bit - and a change in interface is expected to break code
whereas a change in impl, in theory, should not?
Close.
The version triplet major.minor.build generally indicates:
* build changes whenever ANYTHING in the package changes (for a public
release).
* minor changes whenever there is new functionality that is backwards
compatible (say ... we add a new method to an existing class).
* major changes whenever there is a change such that software written to
previous versions will not work (or might not work) with the new version.
This is pretty sketchy, I know. I will try to write up a more complete
description tonight when I get home.
···
--
-- Jim Weirich jim@weirichhouse.org http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
> so the gem versioning concept is similar to the libtool concept
>
> interface.implementation.age
>
> minus the age bit - and a change in interface is expected to break code
> whereas a change in impl, in theory, should not?
Close.
The version triplet major.minor.build generally indicates:
[...]
That's the versioning scheme proposed originally by Eivind Eklund; you
said on the ML it would be the recommended system for use with RubyGems,
but it's quite hard to get to its description from the developer's guide
(2 hops). Would it be possible to show it more prominently?
This is pretty sketchy, I know. I will try to write up a more complete
description tonight when I get home.
You could reuse the original description from
http://rubyforge.org/pipermail/rubygems-developers/2004-April/000294.html
("Proposed version format B").
···
On Thu, Jul 01, 2004 at 06:39:04AM +0900, Jim Weirich wrote:
--
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com
Whoa...I did a 'zcat /vmlinuz > /dev/audio' and I think I heard God...
-- mikecd on #Linux