On Tue, Nov 11, 2008 at 8:59 AM, Berger, Daniel <[EMAIL PROTECTED]>wrote:
> I'd rather not get into mangling version numbers in an attempt to parse
> every arcane schema that users come up with in the wild. However, I'm
> not opposed in principle to the notion of a gem "status" that would more
> or less be in line with the "status" field for RAA downloads, where a
> gem at 'stable' status (or 'production', or whatever you want to call
> it) would supercede a gem at 'prerelease' status.
>
> So, let's say on November 1, 2008 I want to put out a prerelease version
> of "foo" 1.0.0. It would look like this:
>
> Gem::Specification.new do |gem|
> gem.name = 'foo"
> gem.version = '1.0.0"
> gem.status = Gem::Status::PRERELEASE # Or ALPHA, or whatever
> end
>
> A month later I put out the "official" release:
>
> Gem::Specification.new do |gem|
> gem.name = 'foo"
> gem.version = '1.0.0"
> gem.status = Gem::Status::STABLE # The default, btw
> end
>
This approach isn't good because there's no way to version prerelease gems.
Every prerelease gem would be versioned the same, which doesn't work if I
want to distinguish between them. To version prerelease versions, you'd
have to revert back to what Rails is doing anyway, and make the "real"
release end in 1 for the most-minor increment.
On Tue, Nov 11, 2008 at 9:42 AM, Hugh Sasse <[EMAIL PROTECTED]> wrote:
> Could this be done more simply with another "decimal" place?
> Version 2.1.0.1 to 2.1.0.9999
No! This means the new release has the same version as the previous
release. The prerelease isn't the code for version 2.1.0.anything, it's the
code for 2.2.anything. This causes problems for third-party tool
maintainers who want to write and proactively release forward or backward
compatible code against the prerelease by checking for rails version >=2.2,
or <=2.1.
This problem is why I convinced Koz to go with the current approach, which
at least ensures the above version checks can be made sensibly.
> or possibly, as each {major, minor, minor_minor, tiddler} may be
> regarded as an int:
> Version 2.2.0.-99
I believe this is essentially what Josh, Alex, and Phil are going to do, but
by using a non-numeric number rather than a negative number to indicate the
prerelease status, with the addition of a flag to force install of a
prerelease gem. This is essentially the same approach Daniel is proposing,
but with the "prerelease" status automatically determined by the existence
of the non-numeric version component.
I initially thought this was a bad idea, especially since the current Rails
approach works fine, as long as you are not hung up on your first public
release ending in zero.
However, the thing that immediately convinced me otherwise - I'm very
pragmatic ;) - is that this would allow ANY prerelease gem to be pushed to
rubyforge, and people would not automatically pull it down, because the
default would be to NOT download any prerelease gems.
This would help address many of the concerns about people not pushing their
Github (nondefault repo) gems back to RubyForge (default repo), and
facilitate some mechanism that would allow prerelease (and release) gems to
automatically be pushed/pulled from Github to Rubyforge.
I'm really interested to see how they are going to do this without the
non-numeric versions breaking old versions of rubygems, but I'm hopeful :)
-- Chad
_______________________________________________
Rubygems-developers mailing list
Rubygems-developers@rubyforge.org
http://rubyforge.org/mailman/listinfo/rubygems-developers
