Prior to working with AOO, I thought that there was a widely-known and
generally accepted methodology for releasing incompatible changes.
However, the problem has surfaced here three times: once last spring
(encryption default), and twice currently (0⁰, and extensions with
toolbars). I want to try to separate the "how we release it" from the
"should we do it" and the technical details.
The two key points of the method I'm used to are (1) long lead time, and
(2) parallel operation. Introducing a new way and deprecating an old one
are not really disruptive. The disruption comes when support for the old
way is dropped, and something doesn't work any more. Hence, new ways and
deprecations can be issued at any minor release, and the sooner the
better. However, for an organization with so large a following as ours,
we need to allow a lead time of an entire major release (though
circumstances may vary) before dropping support.
As an example, for the extensions change, we should say something like,
"A new method of handling toolbars [link] is provided in AOO 4.0. The
old method is deprecated, and support may be dropped as soon as AOO 5.0.
Extension developers should provide two versions, using MAX_VER and
MIN_VER ..." [Please excuse my ignorance, here.]
Ariel is quite correct to point out that this parallelism doesn't come
for free: it can involve a messy piece of code to be maintained.
However, two points: (a) maintenance in the area should be near zero for
the life of the lead time (unless the area is a target for new
features), and (b) shouldn't we (developers) be doing the hard work, so
our downstream folks have it easier?
Providing parallelism for the Calc 0⁰ problem should be easy enough,
while deferring our proposed change to 5.0. (I favor the change, but not
so suddenly!)
HTH,
/tj/
- Releasing incompatible changes tj
-
