Another 2.0.x release

Hey guys,

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.

[1] http://dev.rubyonrails.org/ticket/10804

Hey Koz,

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.

  • Mislav

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?

Anyone have any reasons we shouldn't do this?

We put this in to prevent people getting auto-updated when their shared host runs a gem update.

The question we should be asking ourselves is whether we want people to get auto-updated on point releases?

If this method of specifying the version would do 2.0.x but not 2.1, then I suppose it’d be fine?

See for yourself:

r = Gem::Requirement.new ‘~>2.0.2’ r.satisfied_by? Gem::Version.new(‘2.0.3’) #=> true r.satisfied_by? Gem::Version.new(‘2.1.0’) => false

Anyone have any reasons we shouldn’t do this?

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 :slight_smile:

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

Thanks, -- Chad

Best case, tests will fail :slight_smile: Users who don't want automatic bug fixes should freeze their app and not rely on shared host's gems anyway.

Worst case, users will complain and then get told that they should (a) write tests, and (b) freeze their app.

I'm +1 on this idea.

Chad,

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.

That is a great idea. Post the patch!

I'm also -1 on this.

I prefer you give an explicit version spec if you actually want it.

jeremy

Hi (and <delurk>),

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.

Stephen Veiss

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...

-- Chad

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?

Heh... not really. All it takes is some sysadmining. I'll try to get it done some time this week.

Hi,

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 led to an issue with fixtures not working in testcases, which is still present in the stable branch. This bug is discussed in http://dev.rubyonrails.org/ticket/10679 and got fixed with a big changeset to trunk: http://dev.rubyonrails.org/changeset/8570

Any possibility of this last changeset being ported to stable?

Cheers,

Menno

+1

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.

Thanks, -- Chad

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>

- Matt

That changeset is fairly intrusive and doesn't seem safe to backport.
Is there a lower-risk alternative out there?

Cheers

Koz

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?

Cheers,

Chris

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.

I've submitted a patch and test: http://dev.rubyonrails.org/ticket/11162

Review and verification is much appreciated.

Cheers,

Menno

No, we won't be backporting performance fixes, our prior experience with that was pretty painful :confused: