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: