On Tue, Nov 4, 2014 at 2:47 PM, Eduard Moraru <[email protected]> wrote: > 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.
This is not a plan, just my point of view. The only thing that was decided is that we can move outside of platform the things that are not bundled in the default distribution. > > 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 -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
