Forum: Rails-core (closed, excessive spam) The thing with Rails 2.0.991 version number

Hi, I'm upgrading to Rails 2.1 pre-release (2.0.991).

The problem with this version number is when people use pessimistic 
version
constraint (like me):

  RAILS_GEM_VERSION = '~> 2.0.2'

I have explicitly defined that I want my app to stay on the "2.0.x" 
stream,
but with the "2.0.991" hack they are going to update to Rails 2.1.

Version numbers (major, minor, tiny) have solid semantics in Rails 
software
and this hack with pre-releases is clearly a violation of them. I just
wanted to bring this to your attention, I don't really have an idea for 
an
alternative to releasing RC software as "2.1.x"

On Mon, May 12, 2008 at 1:29 PM, Mislav Marohniæ 
<mislav.marohnic@gmail.com> wrote:
> Version numbers (major, minor, tiny) have solid semantics in Rails software
> and this hack with pre-releases is clearly a violation of them. I just
> wanted to bring this to your attention, I don't really have an idea for an
> alternative to releasing RC software as "2.1.x"

There is no viable workaround, as far as I can tell. Use a stronger
constraint (= 2.0.2) and change it when you upgrade Rails.

jeremy

2008/5/12 Jeremy Kemper <jeremy@bitsweat.net>:
> On Mon, May 12, 2008 at 1:29 PM, Mislav Marohniæ
>  <mislav.marohnic@gmail.com> wrote:
>  > Version numbers (major, minor, tiny) have solid semantics in Rails software
>  > and this hack with pre-releases is clearly a violation of them. I just
>  > wanted to bring this to your attention, I don't really have an idea for an
>  > alternative to releasing RC software as "2.1.x"
>
>  There is no viable workaround, as far as I can tell. Use a stronger
>  constraint (= 2.0.2) and change it when you upgrade Rails.

This IS a 2.1 branch build, so it should have a 2.1.x.x version.
Releasing it with a 2.0.anything version is just wrong, because it is
not from the 2.0 branch.

The workaround (as I've mentioned in an earlier thread) is to use the
fourth component for release candidates, such as:

2.1.0.xxx

Then, when you cut the final release, call it:

2.1.1

Yes, some people may be disturbed that the initial public release of a
branch does not end in zero, but so what?  The third component is just
signifying that this is some incremental release of the 2.1 branch -
and it actually makes sense that it is not zero, since there have been
previous Release Candidates of the 2.1 branch.

In any case, this semantic nit of not having the initial public
release release end in zero is insignificant and causes no real
problems.  On the other hand, giving a 2.1 branch release a version of
2.0 does cause real problems when trying to use RubyGems versions as
intended, as Mislav notes.

-- Chad

Jeremy: how about this in boot.rb -- http://pastie.org/195736

2008/5/12 Jeremy Kemper <jeremy@bitsweat.net>:

> In any case, this semantic nit of not having the initial public
> release release end in zero is insignificant and causes no real
> problems.  On the other hand, giving a 2.1 branch release a version of
> 2.0 does cause real problems when trying to use RubyGems versions as
> intended, as Mislav notes.

The beta gems are never sent to rubyforge, I think you're overstating
the issues here.   99% of rails' users will never even notice this has
happened.

--
Cheers

Koz

On Mon, May 12, 2008 at 2:03 PM, Mislav Marohniæ 
<mislav.marohnic@gmail.com> wrote:
> Jeremy: how about this in boot.rb -- http://pastie.org/195736

I don't think that is good.  I don't want boot.rb hacking a gem
version that I've already specified.  This will break scenarios where
a specific version of the Rails has already been activated, via
preinitializer.rb, for example.  This will tell gem to try and load a
different version than was already specified and activated, which will
raise an exception.

On Mon, May 12, 2008 at 2:05 PM, Michael Koziarski
<michael@koziarski.com> wrote:
>
>  > In any case, this semantic nit of not having the initial public
>  > release release end in zero is insignificant and causes no real
>  > problems.  On the other hand, giving a 2.1 branch release a version of
>  > 2.0 does cause real problems when trying to use RubyGems versions as
>  > intended, as Mislav notes.
>
>  The beta gems are never sent to rubyforge, I think you're overstating
>  the issues here.   99% of rails' users will never even notice this has
>  happened.

OK, maybe :)

However, I think you are ignoring the issue that giving a 2.1 branch
build a version of 2.0.anything is just wrong.

1% of Rails users is still more than a few users, and to have Rails
actively doing things that go against RubyGems standards and breaks
stuff is not a good thing.  Especially if there is a workaround that
causes no actual failures, and solves a problem which does cause
actual failures.

-- Chad

-- Chad

2008/5/12 Chad Woolley <thewoolleyman@gmail.com>:
> This IS a 2.1 branch build, so it should have a 2.1.x.x version.
> 2.1.1
> 2.0 does cause real problems when trying to use RubyGems versions as
> intended, as Mislav notes.

+1

I'd also like to be working with a 2.1 that's actually 2.1.x, not 2.0.x.

Assaf

On 12 May 2008, at 22:30, Chad Woolley wrote:
>
>
> 1% of Rails users is still more than a few users, and to have Rails
> actively doing things that go against RubyGems standards and breaks
> stuff is not a good thing.  Especially if there is a workaround that
> causes no actual failures, and solves a problem which does cause
> actual failures.
>
It might be more than 1% given that aptana was silently adding
gems.rubyonrails.org to people's gem sources (and re-adding it when
people removed it), although those people were already picking up the
edge rails gems (2.0.2.xxxx) and suffering accordingly.

Fred

On Mon, May 12, 2008 at 2:30 PM, Chad Woolley <thewoolleyman@gmail.com> 
wrote:
>  >  The beta gems are never sent to rubyforge, I think you're overstating
>  stuff is not a good thing.  Especially if there is a workaround that
>  causes no actual failures, and solves a problem which does cause
>  actual failures.

By "just wrong" you mean it violates RubyGems' versioning policy.

It's a tradeoff so we can release 2.1, not 2.1.1. Labeling 2.0.991 as
"just wrong" prohibits any reasonable compromise.

We accept the violation so we can have a clean release version.
Consider it an amendment to RubyGems' policy; call it Rails'
versioning policy; redefine "just wrong."

Best,
jeremy

On May 12, 2008, at 5:44 PM, Frederick Cheung wrote:
> edge rails gems (2.0.2.xxxx) and suffering accordingly.
>
> Fred

Or Rails could adopt a 2.[02468].x is Stable, 2.[13579].x is "edge"
and avoid all the trouble.  If Ruby (and many others) can have the
even-numbered point releases be the stable and the odd-numbered be the
"experimental", why couldn't Rails?

As quickly as the first post-release patches have come out the last
few times, it would be 2.x.(y+1) regardless of whether y starts as 0
or 1.

-Rob

On Mon, May 12, 2008 at 11:51 PM, Jeremy Kemper <jeremy@bitsweat.net> 
wrote:

>
> We accept the violation so we can have a clean release version.
> Consider it an amendment to RubyGems' policy; call it Rails'
> versioning policy; redefine "just wrong."


I can accept that. But can we modify boot.rb as in my pastie then?

@Chad: I didn't understand what did you say the drawback would be?

On Mon, May 12, 2008 at 2:57 PM, Mislav Marohniæ 
<mislav.marohnic@gmail.com> wrote:
> @Chad: I didn't understand what did you say the drawback would be?

Whatever self.gem_version returns in boot.rb is what should be used.
load_rails_gem should not attempt to load a different version, because
it will fail if the prior version has already been loaded.

2008/5/13 Chad Woolley <thewoolleyman@gmail.com>:

> On Mon, May 12, 2008 at 2:57 PM, Mislav Marohnić
> <mislav.marohnic@gmail.com> wrote:
> > @Chad: I didn't understand what did you say the drawback would be?
>
> Whatever self.gem_version returns in boot.rb is what should be used.
> load_rails_gem should not attempt to load a different version, because
> it will fail if the prior version has already been loaded.


You are right, but the hack could be easily moved inside 
self.gem_version.

I don't think of this as dangerous messing with specified versions, I'd 
like
to think of this as safety belt against RCs.

As far as conveyed intention something.99 tells me clearly that's
almost something. Since there are no even/odd releases as of this
writing I am +1 on having a clean version 2.1 stable.

Given the current versioning schema people cannot expect stable
releases using gem sources and wildcards. And if you run edge/RCs I am
sure you are able to understand the current convention and its
implications ("you" being generic).

The right fix in my view, if needed anyway, would be to introduce
odd/even releases in the future.

On Tue, May 13, 2008 at 11:11 AM, Xavier Noria <fxn@hashref.com> wrote:

> As far as conveyed intention something.99 tells me clearly that's
>  almost something.

Heh, I mean something + 1. Looks it is less clear to me when using words 
:-).

On Mon, May 12, 2008 at 5:54 PM, Rob Biedenharn
<Rob.Biedenharn@gmail.com> wrote:

>
>  Or Rails could adopt a 2.[02468].x is Stable, 2.[13579].x is "edge"
>  and avoid all the trouble.  If Ruby (and many others) can have the
>  even-numbered point releases be the stable and the odd-numbered be the
>  "experimental", why couldn't Rails?

Well Ruby used to use that convention, but Matz did away with it with
1.9, Ruby versioning now has x.y.0 as "experimental/development" and
x.y.[123456789] as "production".  Ruby 1.9.1 (whenever it happens)
will be the first production version of 1.9.

--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

On Tue, May 13, 2008 at 5:19 AM, Rick DeNatale <rick.denatale@gmail.com> 
wrote:
>  Well Ruby used to use that convention, but Matz did away with it with
>  1.9, Ruby versioning now has x.y.0 as "experimental/development" and
>  x.y.[123456789] as "production".  Ruby 1.9.1 (whenever it happens)
>  will be the first production version of 1.9.

Which seems to be pretty close to what I am proposing, no?