Proposal: api_compatibility config setting

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?