Hi all,
As already mentioned briefly in my talk at LOCon, we need to make up our
mind how to handle LO extension dependencies.
Each .oxt extension can carry any number of dependencies, specifying
conditions that need to be met by the hosting LO installation for the
extension to be successfully deployable (see
<http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/Extensions/Dependencies>).
The mechanism was designed to allow for any number of fine-grained
dependency specifications ("this extension requires availability of
com.sun.star.whatever.Service"), but only a coarse-grained
OpenOffice.org-minimal-version ever got defined (and also a
maximal-version one). After all, it is hard (or at least tedious) for
extension developers to come up with a precise list of features they
depend on, which would be needed to specify a precise list of
fine-grained dependencies. A single minimal-version dependency appeared
so much easier to use.
The OpenOffice.org-minimal-version dependency worked fine as long as OOo
was the de-facto standard, with derivatives tracking OOo development
rather closely and producing new versions in sync with upstream OOo.
The minimal-version dependency's version value was to be interpreted as
the version of the underlying OOo reference version, so even if a
derivative used a different versioning scheme everything worked out. An
extension developed for one product could also be deployed in a
different one (at least in theory; of course there are always minor
glitches that spoil the picture).
Now, LO and OOo (now AOOo) are no longer in such close relation. LO is
heading towards its version 3.5 already while AOOo did not yet publish
its version 3.4, and new features are routinely added to LO that are
unlikely to be included into AOOo. This leads to the following items:
** How shall LO handle the OpenOffice.org-minimal-version dependency?
Strictly speaking, LO 3.4/3.5 should still check against an
OpenOffice.org-minimal-version value of 3.3, as that's the latest
available (A)OOo version. However, for LO 3.4, this check has (probably
accidentally) been changed to "3.4" (and with the current code towards
LO 3.5 it has yet again changed to "3.5"). I would argue to leave it at
"3.4" for both LO 3.4 and LO 3.5. (For one, it can obviously no longer
be changed back to "3.3" for LO 3.4, and changing it back to "3.3" for
LO 3.5 would probably cause more confusion than its worth. For another,
semantically the check will likely be more-or-less correct, matching the
features an AOOo 3.4 will presumably come out with.) If no one objects,
I will adapt LO 3.5 so that it still checks for "3.4," not "3.5."
In the future, when AOOo releases new versions after AOOo 3.4, we would
need to check whether it semantically makes sense for LO to bump its
OpenOffice.org-minimal-version check (i.e., whether the features of that
new AOOo version are also available in LO).
** How to specify dependencies for newly introduced LO features?
One option would be to add an additional LibreOffice-minimal-version
dependency. Another option would be to actually make use of
fine-grained dependencies and introduce them as needed (i.e., whenever
an extension developer wants to make use of a new LO feature, a
corresponding dependency would have to be added).
The former has as pro its ease of use. The latter has as pro that it
shows a way out of the problems caused by OpenOffice.org-minimal-version
and for an opportunity of continued sharing of extensions across
products: If each extension only lists the features it requires,
regardless of any product's version numbers, it becomes much easier to
match that extension against a given product's capabilities, regardless
of brand.
I'd tend to give the fine-grained dependencies a try. That would
require cooperation from extension developers (they would need to voice
their demand for dependencies for specific features, and they would need
to make accurate use of those dependencies in their extensions). To
achieve cross-product extension compatibility, it would also require
some sort of advertising of LO's newly introduced fine-grained
dependencies (so that other products---where possible---would pick them
up together with the corresponding features), but we would need a place
to document any newly introduced dependencies, anyway.
What do other people think here?
** What happens when LO 4 becomes incompatible?
In that case, any OpenOffice.org-minimal-version dependency, regardless
of version value, should be considered as not satisfied by LO 4.
Similarly, if we did introduce a LibreOffice.org-minimal-version
dependency, any version value of that dependency less than 4 should be
considered as not satisfied. On the other hand, treatment of any
fine-grained dependencies would have to be handled on a case-by-case basis.
Stephan
Context
- [Libreoffice] Extension dependencies · Stephan Bergmann
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.