On Wed, Feb 13, 2013 at 10:32 PM, tj t...@apache.org wrote:
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!)
But note the differing expectations between developers and end-users.
Developers know that code does not last forever. They know that any
non-trivial piece of code needs to to be maintained and adapted due to
changes in dependencies. This could be OS updates, 3rd party library
updates or changes in OpenOffice API's. For extension authors, the
OpenOffice API's are a large part of this dependency chain and they
rely on us to practice good change management techniques to minimize
the disruption when such changes occur. So I think everything you
wrote above applies to the extension authors: they expect that
changes will occur from time to time, and they rely on us to
communicate these changes clearly and with sufficient advance notice
that they can adapt their code in time.
But end-users, the expectations are different. End users expect that
with a new release the UI might change, that features might be
enhanced. They expect that it will require some small amount of time
to adjust to a new upgrade, especially a major one. But when it comes
to THEIR documents (and I emphasize their to show that they consider
this their property, not ours) they have a very low tolerance to
having changes introduced in an upgrade. If the formatting changes
during an upgrade, it is a FAIL. If pages renumber because of an
upgrade, then it is a FAIL. If objects on a slide move after an
upgrade, then it is a FAIL. And if a spreadsheet returns a result
even a penny different, or introduces an error where once a
calculation succeeded, then it is also a big FAIL.
Where spreadsheets have evolved, they have done so very carefully, in
a way that does not break backwards compatibility. For example, Excel
2013 has a legacy CEILING() function, but also a new CEILING.ISO() and
a CEILING.MATH() function. They knew that it would be trouble if they
changed the behavior of the existing function, so they created new
versions to express the new behavior.
In any case, I don't support the idea that end-users should be taught
to expect breaking changes in their documents from release to release
and that they will need to modify their documents to account for the
changes we make. We need the engineering discipline and skill to
avoid such breaking changes. IMHO.
Regards,
-Rob
HTH,
/tj/
