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/ >
