Ok, so we don`t really plan anything for the short term (i.e. consider xe as a flavor and apply the same logic which is basically described in the OP), but instead postpone it until flavors fixes the problem for us. I`m not sure how users feel about this and if this (ability to upgrade important extensions without upgrading war) is something that they really need ASAP or if it can wait, but I guess we`ll have to see how it goes. Thanks, Eduard On Tue, Nov 4, 2014 at 3:33 PM, Thomas Mortagne <[email protected]> wrote:
On Tue, Nov 4, 2014 at 1:55 PM, Eduard Moraru <[email protected]> wrote:
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?
That's the other part on my mail. In my mind flavors have their own life and don't really need to be in sync with their dependencies. So once we get rid of XE and only distribute a minimalistic WAR (with only what is needed to install a flavor) I guess we can move more stuff outside of xwiki-platform.
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 <[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)
Again I talked about extensions not bundled with XE. Please read
http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HTopLevel...
.
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
-- 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
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs