[xwiki-devs] [Discussion] Problems with the way we release extensions done by the XWiki Dev Team
3 Nov
2014
3 Nov
'14
6:44 p.m.
= 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
3 Nov
3 Nov
6:52 p.m.
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 <enygma2002(a)gmail.com> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
7:06 p.m.
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 <thomas.mortagne(a)xwiki.com>
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 <enygma2002(a)gmail.com>
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
7:11 p.m.
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 <enygma2002(a)gmail.com> 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 <thomas.mortagne(a)xwiki.com
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 <enygma2002(a)gmail.com>
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4 Nov
4 Nov
8:41 a.m.
On Mon, Nov 3, 2014 at 7:06 PM, Eduard Moraru <enygma2002(a)gmail.com> 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#HTopLeve….
Thanks,
Eduard
On Mon, Nov 3, 2014 at 7:52 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com>
wrote:
--
Thomas Mortagne
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 <enygma2002(a)gmail.com>
wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs = 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
1:55 p.m.
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?
Thanks,
Eduard
On Tue, Nov 4, 2014 at 9:41 AM, Thomas Mortagne <thomas.mortagne(a)xwiki.com>
wrote:
On Mon, Nov 3, 2014 at 7:06 PM, Eduard Moraru
<enygma2002(a)gmail.com>
wrote:
6.3)
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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#HTopLeve…
.
Thanks,
Eduard
On Mon, Nov 3, 2014 at 7:52 PM, Thomas Mortagne <
thomas.mortagne(a)xwiki.com>
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 <enygma2002(a)gmail.com>
> 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 > >
> > === 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
2:33 p.m.
On Tue, Nov 4, 2014 at 1:55 PM, Eduard Moraru <enygma2002(a)gmail.com> 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 <thomas.mortagne(a)xwiki.com>
wrote:
--
Thomas Mortagne
On Mon, Nov 3, 2014 at 7:06 PM, Eduard Moraru
<enygma2002(a)gmail.com>
wrote:
6.3)
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 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#HTopLeve…
.
Thanks,
Eduard
On Mon, Nov 3, 2014 at 7:52 PM, Thomas Mortagne <
thomas.mortagne(a)xwiki.com>
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 <enygma2002(a)gmail.com>
> 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 > >
> > === 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
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
2:47 p.m.
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 <thomas.mortagne(a)xwiki.com>
wrote:
On Tue, Nov 4, 2014 at 1:55 PM, Eduard Moraru
<enygma2002(a)gmail.com>
wrote:
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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 <
thomas.mortagne(a)xwiki.com>
wrote:
> On Mon, Nov 3, 2014 at 7:06 PM, Eduard Moraru <enygma2002(a)gmail.com>
> 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#HTopLeve…
> .
>
>
> > Thanks,
> > Eduard
> >
> > On Mon, Nov 3, 2014 at 7:52 PM, Thomas Mortagne <
> thomas.mortagne(a)xwiki.com>
> > 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 <enygma2002(a)gmail.com>
> >> 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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs > > 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
> > devs(a)xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
>
>
>
> --
> Thomas Mortagne
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
2:56 p.m.
On Tue, Nov 4, 2014 at 2:47 PM, Eduard Moraru <enygma2002(a)gmail.com> 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 <thomas.mortagne(a)xwiki.com>
wrote:
--
Thomas Mortagne
On Tue, Nov 4, 2014 at 1:55 PM, Eduard Moraru
<enygma2002(a)gmail.com>
wrote:
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 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 <
thomas.mortagne(a)xwiki.com>
wrote:
> On Mon, Nov 3, 2014 at 7:06 PM, Eduard Moraru <enygma2002(a)gmail.com>
> 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#HTopLeve…
> .
>
>
> > Thanks,
> > Eduard
> >
> > On Mon, Nov 3, 2014 at 7:52 PM, Thomas Mortagne <
> thomas.mortagne(a)xwiki.com>
> > 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 <enygma2002(a)gmail.com>
> >> 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
>> > devs(a)xwiki.org
>> > http://lists.xwiki.org/mailman/listinfo/devs
>>
>>
>>
>> --
>> Thomas Mortagne
>> _______________________________________________
>> devs mailing list
>> devs(a)xwiki.org
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
3763
days inactive
3764
days old
8 comments
2 participants
participants (2)
-
Eduard Moraru -
Thomas Mortagne