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”
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.
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.
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.
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.
> 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.
+1
I'd also like to be working with a 2.1 that's actually 2.1.x, not 2.0.x.
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.
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."
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.
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.
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.
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.
