Re: [xwiki-devs] [Discussion] Problems with the way we release extensions done by the XWiki Dev Team

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

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

we have the latest versions specified as dependencies)

Thanks, Eduard On Mon, Nov 3, 2014 at 7:52 PM, Thomas Mortagne <

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 &lt;enygma2002(a)gmail.com&gt; > wrote: > > = Problem = > > > > Extensions managed by the XWiki dev team (in xwiki-platform) are

> 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

> > even if that extension runs perfectly on his older version. > > > > Extensions on contrib do not have this problem, because they can

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

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

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

> > > > = One Solution = > > > > In xwiki-platform, extensions keep using as parent the latest version

> > order to access the latest tools and configurations and to benefit

> > smooth release process where we can release everything at the same > version > > (XWiki's version). However, inside each extenion's pom, they will

> > use the oldest compatible XWiki version possible for their

> 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

> > to an XWiki 5.4 release) we want the distribution wizard to get the

> for > > 5.4 and we want o ensure that all the xar's dependencies are 5.4

> > (the ones corresponding to the 5.4 release) and not the latest (e.g

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

> to > > override the xar's default dependencies versions and specify either a > > manual one or 'latest') or in a diferent step (Add extension or

> > xwiki-platform-administration-ui (5.4) > > > xwiki-platform-rendering-macro-velocity ([4.3,) which is resolved to

> > > > === Possible solution to this problem === > > > > Have the distribution xar ensure that its dependencies' transitive > > dependencies are not the ones specified by the direct dependencies,

> the > > ones corresponsing to the distrubution xar's XWiki version. We could > > probably achieve this by listing in xwiki-enterprise-ui-mainwiki all

> > transitive dependencies that are XWiki artefacts and use > ${project.version} > > for all of them. Perhaps we can automate this with a maven plugin

> > of manually having to maintain this list. Even if we end up

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

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

> > might not want to upgrade to the *latest* (6.3) version of an

> > but he would like instead to remain in the 5.4 LTS version range and

> > only 5.4.1, 5.4.x versions, even 5.x versions as they come, but not

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

_______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs