[Laszlo-dev] Backward compatibility policy of OpenLaszlo

P T Withington ptw at pobox.com
Tue Jul 8 11:28:06 PDT 2008


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.]




More information about the Laszlo-dev mailing list