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