I've spent some time backporting most of the bugfixes from edge to the
2-0-stable branch. If you're currently running on 2.0.2 and feel like
helping out, I'd be really interested in reports of any breakages.
Additionally, the patch in #10804 [1] should probably be backported.
If someone could help out there I'd really appreciate it
Assuming testing goes well we can push out a new point release in the
near future.
What do you guys think of adding a pessimistic version constraint to RAILS_GEM_VERSION in the app skeleton generator?
http://dev.rubyonrails.org/ticket/11069
E.g. to have
RAILS_GEM_VERSION = ‘~> 2.0.2’
instead of locking it to a specific point release
RAILS_GEM_VERSION = ‘2.0.2’
That way applications would use any 2.0.x gem installed that’s higher than 2.0.2, but not 2.1.x. If we had the version constraint in our current applications, now when you roll out 2.0.3 we could have simply installed the gem and automatically benefit from it.
What do you guys think of adding a pessimistic version constraint to
RAILS_GEM_VERSION in the app skeleton generator?
http://dev.rubyonrails.org/ticket/11069
E.g. to have
RAILS_GEM_VERSION = '~> 2.0.2'
instead of locking it to a specific point release
RAILS_GEM_VERSION = '2.0.2'
That way applications would use any 2.0.x gem installed that's higher than
2.0.2, but not 2.1.x. If we had the version constraint in our current
applications, now when you roll out 2.0.3 we could have simply installed the
gem and automatically benefit from it.
We put this in to prevent people getting auto-updated when their
shared host runs a gem update. If this method of specifying the
version would do 2.0.x but not 2.1, then I suppose it'd be fine?
Well, I can think of a reason: when a user didn’t have time/knowledge to understand a bug that he stumbled on, so he built part of the functionality on it (relying on the wrong behavior). Then, when the bug gets fixed the application breaks.
I don't think this is a good idea. By default, all dependencies
should be locked (in gem specs and generated files), to avoid nasty
surprises for people who don't want or don't know how to deal with
them. If you want to float on the newest release, it should be easy
to opt-in - and it is, since I pushed for the patches to allow this
You can't predict the future, it may hold bugs, even in released
"versions" As evidence, see the Test::Unit superclass breakages in
the post ~>2.0 releases
You may be right. As a compromise, could we put in a comment which mentions the constraint above the frozen version? That way people can opt-in to automatically upgrade on point releases.
I tried the current 2-0-stable branch today with postgresql 8.3 and OS
X 10.5.2. Changeset [8828] introduced a slew of AR test failures. The
fix for these is in [8663], which applied cleanly to my 2-0-stable
checkout. With that applied, I have one remaining test failure:
test_native_types(MigrationTest)
[./test/migration_test.rb:324:in `test_native_types'
/Library/Ruby/Gems/1.8/gems/mocha-0.5.6/lib/mocha/
test_case_adapter.rb:19:in `__send__'
/Library/Ruby/Gems/1.8/gems/mocha-0.5.6/lib/mocha/
test_case_adapter.rb:19:in `run']:
<0> expected to be != to
<Rational(0, 1)>.
This is also present in 2.0.2 and edge, so it may well be something to
do with my local setup. As for my applications, they seem to be fine
under 2-0-stable.
Should there be a separate CI build for the stable branch as well?
That would give early warning of these type of problems. It's a good
practice to have your release branch as well as trunk on CI, and I've
suggested this to Alexey. It is easy to do in cc.rb...
Should there be a separate CI build for the stable branch as well?
That would give early warning of these type of problems. It's a good
practice to have your release branch as well as trunk on CI, and I've
suggested this to Alexey. It is easy to do in cc.rb...
Yeah, a stable branch CI build would be fantastic, do you need
anything from us alexey?
Looking forward to a new stable release but I'm wondering if the
issues with ActionController::TestCase can be fixed up in 2.0.x.
Currently there's a bug in 2.0.2 which overrides setup-methods in your
testcase which got fixed in stable with http://dev.rubyonrails.org/ticket/10382
This is definitely a key change we are waiting on (still on 1.99.0 on
some projects because of it), but I haven't had time to dig into the
stable branch and make sure everything works with multi-level testcase
inheritence and setup.
The probability is non-zero, but it goes way up if you get in and give it a
go yourself. You've got the same access to resources as anyone else.
<grin>
I have a local branch of our app on stable HEAD and it all seems to be running fine. I was wondering if http://dev.rubyonrails.org/ticket/11108 will make it to stable?
The probability is non-zero, but it goes way up if you get in and give it a
go yourself. You've got the same access to resources as anyone else.
<grin>
You're absolutely right. The big changeset with all the chaining
scared me a little bit, but I think I've found a simple fix for
stable.