3 Nov
2014
3 Nov
'14
7:11 p.m.
Also, forgot to mention that I have discussed this with Marius offline, as
he helped me with clarifications and identifying the problems of my
proposed solution.
Looking forward to hearing your thoughts on the matter.
Thanks,
Eduard
On Mon, Nov 3, 2014 at 8:06 PM, Eduard Moraru <enygma2002(a)gmail.com> wrote:
This only applies to extensions currently locate in
xwiki-platform. Does
not matter if they are bundled or not in XE.
On that note, if we move all extensions to xwiki-extensions or how we want
to call it, we will be having the same inconveniences we had in the past
when releasing xwiki-enterprise, right? (having to check that in xe pom.xml
we have the latest versions specified as dependencies)
Thanks,
Eduard
On Mon, Nov 3, 2014 at 7:52 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com
wrote:
You are only talking about extensions bundled
with XE right ?
For the other extensions we already decided that we were supposed to
more them to their own repository and own versions (and own
dependencies version like contrib projects). Since we are planning to
reduce the size of XE and move to flavors around 7.x it will probably
be the same for most of the extensions that are currently bundled in
XE.
On Mon, Nov 3, 2014 at 6:44 PM, Eduard Moraru <enygma2002(a)gmail.com>
wrote:
= Problem =
Extensions managed by the XWiki dev team (in xwiki-platform) are
limited to
always depending on the latest version of XWiki.
A user with an older XWiki instance can not install a newer/latest
version
of an extension *without upgrading to the
newer/latest version of XWiki,
even if that extension runs perfectly on his older version.
Extensions on contrib do not have this problem, because they can easily
specify the (possibly older) XWiki version they depend on even if they
are
developed and run perfectly on the latest
version.
As an analogy, imagine Android market where apps are developed with a
minimum supported OS version of 2.2 (the most wide spread) and run
perfectly and are developed on the latest Android 5.0.
We need to be able to do that too, specially with "official" extensions.
== Historical details ==
We have introduced this problem when we moved from the old repository
layout where each module/extension was versioned individually. At each
release, we would have to make sure that the xwiki-enterprise web
contained
the latest versions and it was a PITA. Now, each
module/extension has
the
same version as xwiki-platform/xwiki-enterprise
and we don`t hav to do
that
anymore, however we might have went a bit too far
with the dependencies.
= One Solution =
In xwiki-platform, extensions keep using as parent the latest version in
order to access the latest tools and configurations and to benefit from
a
smooth release process where we can release
everything at the same
version
(XWiki's version). However, inside each
extenion's pom, they will need
to
use the oldest compatible XWiki version possible
for their dependencies
and
stop using ${project.version} or
${platform.version}. E.g. "[4.3,)"
meaning
from 4.3 to the latest
= Problems with the solution =
== Migrations ==
When migrating/upgrading to a fixed version (e.g. the new war
corresponds
to an XWiki 5.4 release) we want the distribution
wizard to get the xar
for
5.4 and we want o ensure that all the xar's
dependencies are 5.4
versions
(the ones corresponding to the 5.4 release) and
not the latest (e.g
6.3).
If the user wants to upgrade some individual extensions to the latest
version, he can do that either in the current step (in the install plan
to
override the xar's default dependencies
versions and specify either a
manual one or 'latest') or in a diferent step (Add extension or
Extension
Updater sections in Administration).
=== Example ===
We want:
xwiki-enterprise-ui-mainwiki (5.4) > xwiki-enterprise-ui-common (5.4) >
xwiki-platform-administration-ui (5.4) >
xwiki-platform-rendering-macro-velocity (5.4)
Instead of:
xwiki-enterprise-ui-mainwiki (5.4) > xwiki-enterprise-ui-common (5.4) >
xwiki-platform-administration-ui (5.4) >
xwiki-platform-rendering-macro-velocity ([4.3,) which is resolved to
6.3)
=== Possible solution to this problem ===
Have the distribution xar ensure that its dependencies' transitive
dependencies are not the ones specified by the direct dependencies, but
the
ones corresponsing to the distrubution xar's
XWiki version. We could
probably achieve this by listing in xwiki-enterprise-ui-mainwiki all the
transitive dependencies that are XWiki artefacts and use
${project.version}
for all of them. Perhaps we can automate this
with a maven plugin
instead
of manually having to maintain this list. Even if
we end up maintaining
a
list, it will not be something that changes very
often.
== LTS environment encapsulation leaks ==
After the migration is complete and the user is now using 5.4, he might
want, at some point to upgrade some of his extensions to benefit from
minor
bugfixes. Considering that his current 5.4
version is a LTS version, he
might not want to upgrade to the *latest* (6.3) version of an extension,
but he would like instead to remain in the 5.4 LTS version range and get
only 5.4.1, 5.4.x versions, even 5.x versions as they come, but not go
to
6.x or newer/unsafe versions.
This problem should be addressed by the Extension Updater UI and,
possibly
allowing the user to specify if he wants a
specific/manual version
(regardless of LTS or latest) or the latest version (a. from the current
cycle, i.e. LTS or b. the latest one available, i.e. 6.3+)
WDYT?
Thanks,
Eduard
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs