TL;DR - should we add a config.api_compatibility to make the upgrade path for behavioural changes more straightforward? ------- When we want to change or remove a user-facing feature, we add a deprecation to provide an upgrade path. Sometimes we cannot detect how a user is using a certain feature. If we''re simply removing a method, it''s easy to add a deprecation to that method and get no false positives. But if we are changing a behaviour of a method, we don''t know whether people are relying on the previous behaviour in their own code. An example of this is the recent change to :dependent => :restrict https://github.com/rails/rails/commit/336ff8a What generally happens in these cases is either: * a configuration option gets added to newly generated apps to differentiate them, or * the change doesn''t get made because it is too much hassle I believe that the proliferation of config option that change *behaviour* is harmful. It means that your AR objects (for example) are no longer defined solely by the code in app/models/, but also by a bunch of stuff in config/. If you want to use that code outside of a full Rails environment, it will behave differently. We could add an API compatibility config option: config.api_compatibility = "3.1" On each release, a config.api_compatibility option with a value below the current version would trigger a deprecation warning. If config.api_compatibility is nil, we would assume the current version. Pros: * Makes deprecation easier. If we''re changing behaviour, we can use the api_compatibility to differentiate between older and newer apps. * Removes the need for adding lots of config options for deprecation, replaces it with one. Cons: * It''s all-or-nothing. When upgrading, the user has to basically note down all the deprecations they get, update the api_compatibility, then fix stuff. * It''s another step the user has to take when upgrading (but they can delay it). * It''s a bit crap for people using e.g. Active Record outside of a full Rails app, as unless they explicitly set the api_compatibility option they''ll just get bumped to the latest api_compatibility immediately when they upgrade. I''m not sure what I think about this, but I''m leaning towards liking it as anything that makes the upgrade path for behavioural changes clearer and easier seems like a good thing. I''m also not sure what to do about adding this in. I really don''t want to make config.api_compatibility == nil imply < 4.0, because I think the compatibility should be the latest unless explicitly specified otherwise. Thoughts welcome. -- http://jonathanleighton.com/ -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Rails should just follow SemVer instead. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On 09/03/12 14:22, Steve Klabnik wrote:> Rails should just follow SemVer instead.Assuming Rails did follow SemVer, are you suggesting that we would then just change/remove features between major versions without a deprecation path?! I think people would probably write more ''Rails sucks'' articles if we did that. -- http://jonathanleighton.com/ -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
No, but moving versioning into a configuration option is not the way to do this kind of thing. I''m going to pick arbitrary examples based on another thread in Rails core right now: Rails 3.3: scaffolding considered deprecated. Add deprecation warnings to all scaffolding stuff. Rilas 3.4: yep, still deprecated Rails 4.0: scaffolding removed. I know there will be no rails 3.3 and 3.4, like I said, arbitrary. Deprecation is good. Doesn''t mean we should add _another_ way to determine API compatibility on top of the already existing version numbers. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On 09/03/12 15:56, Steve Klabnik wrote:> Rails 3.3: scaffolding considered deprecated. Add deprecation warnings > to all scaffolding stuff. > Rilas 3.4: yep, still deprecated > Rails 4.0: scaffolding removed.This example does not demonstrate the problem I am trying to solve. The problem is when behaviour changes, not when stuff gets removed. Suppose rails has a #lol method. Currently #lol return "lol". We want to make it return "omg". How do we know whether a user is relying on the current return value of "lol", in order to give them a deprecation warning? -- http://jonathanleighton.com/ -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Fri, March 9, 2012 09:22, Steve Klabnik wrote:> Rails should just follow SemVer instead. >+1 -- *** E-Mail is NOT a SECURE channel *** James B. Byrne mailto:ByrneJB@Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
> This example does not demonstrate the problem I am trying to solve. The > problem is when behaviour changes, not when stuff gets removed.SemVer still handles this case.> Suppose rails has a #lol method. Currently #lol return "lol". We want to > make it return "omg". How do we know whether a user is relying on the > current return value of "lol", in order to give them a deprecation warning?This is not backwards compatible. Therefore, a major version should be increased when it changes. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On 09/03/12 18:05, Steve Klabnik wrote:> This is not backwards compatible. Therefore, a major version should be > increased when it changes.I feel like this is going round in circles a bit, but... Introducing backwards incompatible changes without an upgrade path is not something that Rails currently does. I guess you are saying that you think Rails should just do that, coupled with adopting SemVer. Which is fair enough. Personally I think this would lead to people become more, not less, frustrated with the upgrade process though. Which would not be good, IMO. Hence I was trying to explore alternatives. -- http://jonathanleighton.com/ -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
> I guess you are saying that you think Rails should just do that, coupled > with adopting SemVer. Which is fair enough.Yes! I agree that the current situation with Rails (and with Ruby, for that matter...) is unfortunate. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Fri, March 9, 2012 12:33, Jon Leighton wrote:> On 09/03/12 15:56, Steve Klabnik wrote: >> Rails 3.3: scaffolding considered deprecated. Add >> deprecation warnings >> to all scaffolding stuff. >> Rilas 3.4: yep, still deprecated >> Rails 4.0: scaffolding removed. > > This example does not demonstrate the problem I am > trying to solve. The problem is when behaviour changes, > not when stuff gets removed. > > Suppose rails has a #lol method. Currently #lol return > "lol". We want to make it return "omg". How do we know > whether a user is relying on the current return value of > "lol", in order to give them a deprecation warning? >If you actually do that then you have in fact deprecated lol (old) and replaced it with lol (new) and you have NOT provided a deprecation/update path. Following SemVer that automatically forces a major number increment. Let us consider how methods are actually used. If lol (new) extends the signature in addition to changing the behaviour then the expected behaviour may be specified. If the extended signature is used then return "omg", otherwise return "lol" + deprecation warning. However, in this case I think it best simply to deprecate the lol method and use a different name for the new one. Letters are cheap, labour is not. Why create busy work? -- *** E-Mail is NOT a SECURE channel *** James B. Byrne mailto:ByrneJB@Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.