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

So the ones that will be left still bundled with XE (AWM, Administration, User Directory, etc.) will *still* have the issues in the OP, right? What do we do about them?

Thanks, Eduard On Tue, Nov 4, 2014 at 9:41 AM, Thomas Mortagne <

wrote: > On Mon, Nov 3, 2014 at 7:06 PM, Eduard Moraru &lt;enygma2002(a)gmail.com&gt; > wrote: > > This only applies to extensions currently locate in xwiki-platform.

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

> > when releasing xwiki-enterprise, right? (having to check that in xe > pom.xml > > we have the latest versions specified as dependencies) > > > > Again I talked about extensions not bundled with XE. Please read > >

> . > > > > Thanks, > > Eduard > > > > On Mon, Nov 3, 2014 at 7:52 PM, Thomas Mortagne < > thomas.mortagne(a)xwiki.com&gt; > > 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 > 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

> >> are > >> > developed and run perfectly on the latest version. > >> > > >> > As an analogy, imagine Android market where apps are developed

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

> >> > layout where each module/extension was versioned individually. At

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

> the > >> > same version as xwiki-platform/xwiki-enterprise and we don`t hav

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

> 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

> >> > version, he can do that either in the current step (in the install > plan > >> to > >> > override the xar's default dependencies versions and specify

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

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

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

> 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

> >> > probably achieve this by listing in xwiki-enterprise-ui-mainwiki

> 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

> >> minor > >> > bugfixes. Considering that his current 5.4 version is a LTS

> 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

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