Rails 3.0.6.rc1

rubyonrails-talk
1

ZOMG HAPPY TUESDAY (UTC-7)!!! <3<3<3<3<3

I am happy to announce that the first release candidate for Rails 3.0.6 has been pushed to rubygems.org.

## Release Candidate: What does it mean?

The release candidate is very similar to what we will actually release for version 3.0.6. The reason that we release an RC is so that the community can have a chance to postpone or veto commits that have happened between the previous version and the version we're about to release.

We are asking you (yes you!) to *try out* the release candidate. If something that changed between 3.0.5 and this release candidate breaks your application, we want to know about it!

## How do I try it out?

Simply update your Gemfile to point at the rails version "3.0.6.rc1", then `bundle install`.

## Where can I see a list of Changes?

Either look at the CHANGELOG in each particular project on [github](https://github.com/rails/rails/tree/3-0-6), *or* check out the handy [compare view](https://github.com/rails/rails/compare/v3.0.5...v3.0.6.rc1).

Again, per project changelogs:

  https://github.com/rails/rails/tree/3-0-6

*or* compare view:

  https://github.com/rails/rails/compare/v3.0.5...v3.0.6.rc1

## ZOMG SOMETHING BROKE, WHAT DO I DO?

Email the [rails core mailing list](http://groups.google.com/group/rubyonrails-core) at let us know about the problem! We will discuss the problem and how to handle it before the final version is pushed.

## WHEN WILL THE FINAL VERSION BE RELEASED?!?!?!

Unless there are problems found in the RC, we will release the final version no less than 72 hours from *now*, but not exactly 72 hours from now (as I will be on vacation :-P).

If there are problems found in the RC, we will release another RC and give the community another chance to test before releasing.

## IN CLOSING

Remember, this is *your* chance to veto / postpone our release. Despite the lols I have in this email, please take advantage of this opportunity! We do not want to break people's applications. The best we can do is ask for help!

Thanks for listening everyone!

<3 <3 <3 <3 <3

2

You should run bundle update rather than bundle install, because bundle update ignores & updates the Gemfile.lock file, whereas bundle install doesn’t.

3

ActiveModel::Name does not have :i18n_key method anymore.

Robert Pankowecki

4

I also found a bug that occurs on 3.0.5

ruby-1.9.2-p136 :004 > Time.now => 2011-03-30 01:15:20 +0200 ruby-1.9.2-p136 :005 > Date.today => Wed, 30 Mar 2011 ruby-1.9.2-p136 :006 > Date.yesterday => Mon, 28 Mar 2011 ruby-1.9.2-p136 :007 > Time.zone => (GMT+00:00) UTC ruby-1.9.2-p136 :008 > Date.tomorrow => Wed, 30 Mar 2011

As you can see the simple expectation that yesterday = today -1 and tomorrow = today + 1 is apparently not true in some cases. This problem probably happens around midnight in some zones...

Do you want me to create tickets for them ? Robert Pankowecki

5

Yep, this breaks my app too.

This commit is the culprit: https://github.com/rails/rails/commit/f80eea3bf30dcceaca3c4a9cd9238bdc44a9e165

6

I thank that because this bug has been around since 3.0.2 version: https://rails.lighthouseapp.com/projects/8994/tickets/6034-human_attribute_name-scopes-translations-differently-for-nested-classes-since-rails-302 lot of people assumed that using '.' instead of '/' is the new way of doing things in rails 3 and already changed their scopes in yml files and follow "the new convention".

I also already started following a convention of namespacing classes only in modules (never in another classes) because of problems mentioned in https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/6448-i18n-key-collision-with-namespaced-models#ticket-6448-11

I would have: class Articles module Articles class Articles::Articles

This a big break in API and it happens second time during last 5 releases. Could we clarify this thing once for all the time?

Robert Pankowecki

7

I meant

class Articles module Articles class Articles::Category

8

This issue started here:

https://rails.lighthouseapp.com/projects/8994/tickets/3768-patch-add-full_message-option-to-validations#ticket-3768-69

Then Jos� Valim thought it was a bug and asked me to create another issue:

https://rails.lighthouseapp.com/projects/8994/tickets/5572

Then, this issue was created:

https://rails.lighthouseapp.com/projects/8994/tickets/6448

Then Valim reverted 5572.

Now I know that my i18n locale files should be written like this:

pt-BR:    activerecord:      errors:        models:          my_module/order:            attributes:               amount:                  not_a_number: deve ser um n�mero

I think there will be no more confusing regarding this behavior now we all know what to expect. Maybe there is some documentation missing, regarding modules and i18n keys.

Best regards,

Rodrigo.

9

There are two problems here.

The first problem is that the public API changed between 3.0.5 and 3.0.6.rc1: the i18n_key method was removed. This is a breaking change for applications (mine included) that used this method themselves. To fix this, the method should be restored, with either the 3.0.5 definition or a new definition (depending on the solution for the second, more difficult problem).

The second problem is that we now have two competing conventions for where to place translations for attributes of nested models. 3.0.0-3.0.1 used one convention (‘module/model’), 3.0.2-3.0.5 used another (‘module.model’), and now in 3.0.6 is reverting to the first convention. The change from 3.0.1 to 3.0.2 broke all translations which followed the original convention, and for users on 3.0.2-3.0.5, the change from 3.0.5 to 3.0.6 will break them again. In order to avoid this breaking change, I suggest that we keep ‘module/model’ as the documented preferred convention, but for compatibility, try ‘module.model’ if no translation is found under ‘module/model’.

10

I agree we should support both for now, and deprecate one. I'll come up with a test and fix, and we'll release a new RC.

Thanks for reporting this!

11

Yes please. Does this happen on 3.0.4 too?

12

I agree we should support both for now, and deprecate one. I'll come up with a test and fix, and we'll release a new RC.

Or we could add a setting which version you prefer.

Thanks for reporting this!

Thanks for RC release and the ability to test and veto :slight_smile:

Robert Pankowecki

13

Yes 3.0.4, 3.0.5, 3.0.6.rc1, maybe even earlier versions.

https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/6654-dateyesterday-and-datetomorrow-returns-wrong-values

Robert Pankowecki

14

>> As you can see the simple expectation that yesterday = today -1 and >> tomorrow = today + 1 is apparently not true in some cases. This >> problem probably happens around midnight in some zones... >> >> Do you want me to create tickets for them ? > > Yes please. Does this happen on 3.0.4 too?

Yes 3.0.4, 3.0.5, 3.0.6.rc1, maybe even earlier versions.

We'll discuss this on LH, but this ticket won't block the release.

#6654 Date.yesterday and Date.tomorrow returns wrong values - Ruby on Rails - rails

Thanks for filing this!

15

Just so we're on the same page, we would expect this test to pass:

diff --git a/activemodel/test/cases/translation_test.rb b/activemodel/test/cases/translation_test.rb index 1db63e1..0584606 100644 --- a/activemodel/test/cases/translation_test.rb +++ b/activemodel/test/cases/translation_test.rb @@ -39,6 +39,15 @@ class ActiveModelI18nTests < ActiveModel::TestCase      assert_equal 'person gender attribute', Person::Gender.human_attribute_name('attribute')    end

+ def test_translated_model_attributes_with_attribute_matching_namespaced_model_name_and_dot + assert_deprecated do + I18n.backend.store_translations 'en', :activemodel => {:attributes => {:person => {:gender => 'person gender'}, :"person.gender" => {:attr + end

16

Fixed that for you. :slight_smile:

17

Sorry, I meant this:

diff --git a/activemodel/test/cases/translation_test.rb b/activemodel/test/cases/translation_test.rb index 1db63e1..4deffc3 100644 --- a/activemodel/test/cases/translation_test.rb +++ b/activemodel/test/cases/translation_test.rb @@ -39,6 +39,15 @@ class ActiveModelI18nTests < ActiveModel::TestCase      assert_equal 'person gender attribute', Person::Gender.human_attribute_name('attribute')    end

+ def test_translated_model_attributes_with_attribute_matching_namespaced_model_name_and_dot + assert_deprecated do + I18n.backend.store_translations 'en', :activemodel => {:attributes => {:person => {:gender => 'person gender'}, :"person.gender" => {:attribute => 'person gender attribute'}}} + end

18

No, it’s in spirit something more like:

def test_deprecated_namespaced_model_attribute_translation

assert_deprecated do

I18n.backend.store_translations ‘en’, :activemodel => {:attributes => {:person => {:gender => {:attribute => ‘person gender attribute’}}}}

end

assert_equal ‘person gender attribute’, Person::Gender.human_attribute_name(‘attribute’)

end

I’m not sure how to make the assert_deprecated part of that pass though…

BTW, have a great vacation! :slight_smile:

19

Attached is my proposed patch for the translation issue. I think we should support both conventions and deprecate neither. The newer convention is cleaner when you nest multiple models within one namespace:

en:

activemodel:

 models:

   namespace:

     model_one:

       one: Model One

       other: Model Ones

     model_two:

       one: Model Two

       other: Model Twos

Vs:

en:

activemodel:

 models:

   namespace/model_one:

     one: Model One

     other: Model Ones

   namespace/model_two:

     one: Model Two

     other: Model Twos

The newer convention fails only when you nest models within models, which is probably uncommon compared to nesting models in modules. In that case, if you use the old namespace/model convention, the lookup following the old convention will simply fail, and I18n.translate will move on and try the namespace/model convention. So I think it’s safe to support both.

0001-Support-both-conventions-for-translations-for-namesp.patch (3.65 KB)