Rails core - Jul 2005 - Proposal for backwards compatibility

Hey guys,

This has been bandied around in IRC for a while,  but I thought I''d
email it out to get people''s thoughts.

We need some kind of rule on where to draw the line for backwards
compatibility,   There are two extremes:

1) Win16 - Everything will always work, including weird memory allocator bugs.
2) FreeForall - Nothing will ever work, upgrades are a risky prospect.

There has to be a middle ground,   I propose something like this:

# No more inflector changes

These can break peoples apps,  sure we''ll have some dumb
''bugs'', but
we should''ve caught the majority of cases now.   Catching the rest is
an intractable problem.

# Deprecate the use of instance variables for @request, @flash etc.

The accessors are much easier for us to provide backwards compatibility for

def flash
  lazy_loaded_bpel_powered_awesome_ws_reliable_messaging_replacement_for_flash()
end

# if it''s not in the docs, it''s not supported.

There are a bunch of methods on AR::Base and others which are
''private'',   we can''t commit to supporting them
forever as it ties up
our ability to change the implementation.   We could go as far as
starting all our ''internal'' methods with an underscore, but
that may
be going a tiny bit crazy.


Does anyone have any other thoughts?    I''d like to have a policy put
out so we can justify rejecting / delaying tickets.

-- 
Cheers

Koz

> # No more inflector changes
> 
> These can break peoples apps,  sure we''ll have some dumb
''bugs'', but
> we should''ve caught the majority of cases now.   Catching the rest
is
> an intractable problem.
I agree we shouldn''t introduce new general rules since that might
change the inflection of other unintended words. At most, we should
allow in some obvious irregular words since they don''t break anything.
I don''t think we need to commit to staying with obvious wrong
inflections, but new general rules are just too dangerous at this
point. I agree.
> # Deprecate the use of instance variables for @request, @flash etc.
> 
> The accessors are much easier for us to provide backwards compatibility for
> 
> def flash
>  
lazy_loaded_bpel_powered_awesome_ws_reliable_messaging_replacement_for_flash()
> end
Yup.
> # if it''s not in the docs, it''s not supported.
> 
> There are a bunch of methods on AR::Base and others which are
> ''private'',   we can''t commit to supporting them
forever as it ties up
> our ability to change the implementation.   We could go as far as
> starting all our ''internal'' methods with an underscore,
but that may
> be going a tiny bit crazy.
Definitely. Private methods and undocumented protected ones are your own affair.

It would be good to have a mini-guide to How To Create Tickets in
general. So we can raise the level of ticket quality.
-- 
David Heinemeier Hansson
http://www.loudthinking.com -- Broadcasting Brain
http://www.basecamphq.com   -- Online project management
http://www.backpackit.com   -- Personal information manager
http://www.rubyonrails.com  -- Web-application framework

> I agree we shouldn''t introduce new general rules since that might
> change the inflection of other unintended words. At most, we should
> allow in some obvious irregular words since they don''t break
anything.
> I don''t think we need to commit to staying with obvious wrong
> inflections, but new general rules are just too dangerous at this
> point. I agree.
So if we can easily create specific mappings for a given word this will be fine.

Also,  what about index -> indexes

    * Index in the sense of an ordered list has the plural form indexes.
    * Index in the sense of a number or variable has the plural indices.

 
> > # Deprecate the use of instance variables for @request, @flash etc.
> 
> Yup.
@flash is in the agile book though,  so we''ll make ''more
better best
efforts'' for that one.  The others are gone.
> Definitely. Private methods and undocumented protected ones are your own
affair.
> 
> It would be good to have a mini-guide to How To Create Tickets in
> general. So we can raise the level of ticket quality.
OK,  Once we''ve got strongspace running I''ll spend a little
time on
something like this.  Plus a draft statement for:

"thanks for the suggestion, but that will break other people''s
apps so
we''ll have to live without it"


-- 
Cheers

Koz