[ANN] Rails 3.0.6.rc1

[Aaron Patterson]

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

--
Aaron Patterson
http://tenderlovemaking.com/

[Ryan Bigg]

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

-- 
Ryan Bigg

[Robert Pankowecki]

On Tue, Mar 29, 2011 at 11:30 PM, Ryan Bigg <radarl...@gmail.com> wrote:
> 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!

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

Robert Pankowecki

[Robert Pankowecki]

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

[John Firebaugh]

Yep, this breaks my app too.

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

[Robert Pankowecki]

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

[Robert Pankowecki]

I meant

class Articles
module Articles
class Articles::Category

[Rodrigo Rosenfeld Rosas]

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.

[John Firebaugh]

On Wed, Mar 30, 2011 at 5:47 AM, Rodrigo Rosenfeld Rosas <rr.r...@gmail.com> wrote:

 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.

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

[Aaron Patterson]

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!

[Aaron Patterson]

Yes please. Does this happen on 3.0.4 too?

[Robert Pankowecki]

On Wed, Mar 30, 2011 at 5:54 PM, Aaron Patterson
<aa...@tenderlovemaking.com> wrote:

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

Robert Pankowecki

[Robert Pankowecki]

On Wed, Mar 30, 2011 at 5:55 PM, Aaron Patterson
<aa...@tenderlovemaking.com> wrote:
>> 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.

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

Robert Pankowecki

[Aaron Patterson]

On Wed, Mar 30, 2011 at 08:33:28PM +0200, Robert Pankowecki wrote:
> On Wed, Mar 30, 2011 at 5:55 PM, Aaron Patterson
> <aa...@tenderlovemaking.com> wrote:
> >> 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.

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

Thanks for filing this!

[Aaron Patterson]

On Wed, Mar 30, 2011 at 08:18:45AM -0700, John Firebaugh wrote:

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
+
+ assert_equal 'person gender', Person.human_attribute_name('gender')
+ assert_equal 'person gender attribute', Person::Gender.human_attribute_name('attribute')
+ end
+
def test_translated_model_names
I18n.backend.store_translations 'en', :activemodel => {:models => {:person => 'person model'} }
assert_equal 'person model', Person.model_name.human

If that's true, I'll try to get another RC out tonight. If not, we may have to wait for a few days as I'll be on vacation. :-(

[Ernie Miller]

On Mar 30, 2011, at 7:18 PM, Aaron Patterson wrote:
> I'll be on vacation. :-D

Fixed that for you. :)

[Aaron Patterson]

On Wed, Mar 30, 2011 at 08:18:45AM -0700, John Firebaugh wrote:

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
+
+ assert_equal 'person gender', Person.human_attribute_name('gender')
+ assert_equal 'person gender attribute', Person::Gender.human_attribute_name('attribute')
+ end
+
def test_translated_model_names
I18n.backend.store_translations 'en', :activemodel => {:models => {:person => 'person model'} }
assert_equal 'person model', Person.model_name.human

--
Aaron Patterson
http://tenderlovemaking.com/

[John Firebaugh]

On Wed, Mar 30, 2011 at 4:29 PM, Aaron Patterson <aa...@tenderlovemaking.com> wrote:

+  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
+
+    assert_equal 'person gender', Person.human_attribute_name('gender')
+    assert_equal 'person gender attribute', Person::Gender.human_attribute_name('attribute')
+  end
+

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! :-)

[John Firebaugh]

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.