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 <[email protected]> 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 > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
