wxruby users - Jul 2005 - Wxruby2 gemspec

Hi

A gemspec for installation of wxuby-swig via rubygems. It assumes the 
end-users will compile the pre-swigged .cpp files & that that the main 
require file will be wx.rb (as per Kevin''s suggestion).  runrake.rb is 
just a helper script that runs rake correctly within the rubygems 
installation process.

# to build the gem
gem build wxruby2.gemspec

# to build & install the built gem
gem install wxruby2

will do a win32 gem once binaries are available for a release.

cheers
alex



_______________________________________________
wxruby-users mailing list
wxruby-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/wxruby-users

Alex Fenton wrote:
> WXRUBY2_GEMSPEC = Gem::Specification.new do | s |
>   s.name = ''wxruby2''
>   s.version = ''0.20''
Hi,

Is there a reason for not using the rubygems versioning policy?
http://docs.rubygems.org/read/chapter/7

I''m just curious.

   Robin

Hi Robin

Thanks - it''s not down to me, but seems to me like a good idea to use 
this scheme for versioning. I''m sure this is planned for the final 
release (2.x.x was suggested) but I think it would be useful to follow 
it for the pre-release wx-swig versions to ease use and upgrading via 
rubygems.

The question would be what version number to use. Perhaps it could be 
0.9.0, towards a 1.0.0 swig-based wxruby(2)? release?

cheers
alex
>
> Is there a reason for not using the rubygems versioning policy?
> http://docs.rubygems.org/read/chapter/7
>
> I''m just curious.
>
>   Robin

Alex Fenton wrote:
> 
> Thanks - it''s not down to me, but seems to me like a good idea to
use
> this scheme for versioning. I''m sure this is planned for the final
> release (2.x.x was suggested) but I think it would be useful to follow 
> it for the pre-release wx-swig versions to ease use and upgrading via 
> rubygems.
> 
> The question would be what version number to use. Perhaps it could be 
> 0.9.0, towards a 1.0.0 swig-based wxruby(2)? release?
Yes, I agree that the rubygems proposed versioning scheme makes sense, 
and we''ll try to adopt it for wxruby2.

I am struggling with version numbers for the pre-release versions of 
wxruby2. For now, I am continuing with the 0.0.xx releases that were 
started with wxruby-swig. We are up to 0.0.20. As soon as we have a 
plausible near-release candidate, I will switch to 2.0.0-rc1, and from 
then on we''ll have "normal" release numbers.

I considered using 0.9, but that would be confusing with our wxruby 0.6 
stable release. I thought about 1.9 but that seems even worse. I even 
considered doing 2.0.0 that isn''t actually a 2.0 release, but that
seems
even worse than the other two. So I''m back to 0.0.21.

Hopefully this state won''t last long.

Kevin

Robin Stocker wrote:
> Alex Fenton wrote:
> 
>> WXRUBY2_GEMSPEC = Gem::Specification.new do | s |
>>   s.name = ''wxruby2''
>>   s.version = ''0.20''
Ah. I just noticed this. The current wxruby2 release is 0.0.20, not 0.20.

Kevin

> Ah. I just noticed this. The current wxruby2 release is 0.0.20, not 0.20.
OK, thanks, I''ll correct. That should work fine with rubygems. I need
to
add a line for the ruby loader/wrapper wx.rb - I''ll assume
this''ll be in
lib/wx.rb in CVS.

On versions - perhaps if we''re renaming the package we should release 
wxruby2 1.0.0 - by analogy with sqlite (which has versions 1.x.x and 
2.x.x) and sqlite3 (which has version 1.x.x).

alex

Alex Fenton wrote:
> OK, thanks, I''ll correct. That should work fine with rubygems. I
need to
> add a line for the ruby loader/wrapper wx.rb - I''ll assume
this''ll be in
> lib/wx.rb in CVS.
Correct.
> On versions - perhaps if we''re renaming the package we should
release
> wxruby2 1.0.0 - by analogy with sqlite (which has versions 1.x.x and 
> 2.x.x) and sqlite3 (which has version 1.x.x).
Yes, that is an option, especially since we never released a 1.0 version 
of wxruby1. I lean toward 2.0.0, but am open to other opinions.

Kevin