TL;DR - should we add a config.api_compatibility to make the upgrade path for behavioural changes more straightforward?
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.
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.
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?
+1
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.
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.
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.
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?
