I'd like to restate/clarify our backward-compatibility policy for both
our users and developers, since there appears to have been some
confusion lately.
Our rule of thumb is, when deprecating a feature, we support it for
one whole release along with the replacement feature so that client
code has a release to adapt. More explicitly:
Release N-1: Feature X exists.
Release N: Deprecate feature X, introduce replacement feature Y.
Release N+1: Remove feature X.
In release N, client code will get a warning when using feature X, and
they can change to using feature Y to silence that warning. When
release N+1 comes out, if they have no warnings in release N, their
code will continue to work.
---
What we can't do:
Release N: Feature X exists
Release N+1: Remove feature X, introduce replacement feature Y.
That would be a bug, because the client has no release to migrate from
the old to the new way. (Example: in 4.1 we removed the state
`apply` attribute and replaced it with `applied`. From an
implementation point of view, it made great sense, but from a client
point of view, we shot them in the foot.)
---
[Question: Is N a major or minor version number? In previous
lifetimes, I would have said major, but it seems that with OpenLaszlo
N is a minor version number. Certainly N is not a 'point' or sub-
minor version number.]
