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

= 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