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