[xwiki-devs] [discussion] Synchronizing version numbers of applications, plugins, and core.
6 Oct
2010
6 Oct
'10
2:28 p.m.
I have been observing problems with the versioning scheme which we are using.
Because applications are not branched along with core, when a bugfix version of a stable
branch is
released, new versions of applications are typically pulled in. This means that
`experimental' code
is being introduced into a `stable' branch in a bugfix version. This is not the path I
would choose
but more importantly we can't honestly say that our code goes through a
milestone/release candidate
verification process if some of the code is allowed to bypass it.
This situation has caused me to make a mistake which I was able to correct during the
release
without major issue, I think the same issue is behind the release of 2 bogus versions
(2.4.1 and 2.4.2)
There is another issue, users who want to mix and match applications to build their own
wiki are
faced with a set of version numbers and no way to know what is compatible with what. A
user who I
spoke with last night had this very problem. We could publish a compatibility matrix but
if we were
to show all the versions a given application is compatible with, that would require
testing each
application version against each core version and I think we need to concentrate on
testing what
gets released in XE.
Both of these problems would be fixed if version numbers were synchronized and everything
was
branched for a release. Relevant questions which come to mind are "do we need the
capability to
release applications at separate times?" and "is there no way to do that with
synchronized version
numbers?"
Am I missing any other reasons?
Should this not become a proposal?
Caleb
6 Oct
6 Oct
5:16 p.m.
I'm totally +1 on synchronizing version numbers, this has absolutely no
disadvantages vs. the current situation (we are already always releasing
the apps together with the core), but makes it much easier to release
and to use.
Alex
On 10/06/2010 02:28 PM, Caleb James DeLisle wrote:
I have been observing problems with the versioning
scheme which we are using.
Because applications are not branched along with core, when a bugfix version of a stable
branch is
released, new versions of applications are typically pulled in. This means that
`experimental' code
is being introduced into a `stable' branch in a bugfix version. This is not the path
I would choose
but more importantly we can't honestly say that our code goes through a
milestone/release candidate
verification process if some of the code is allowed to bypass it.
This situation has caused me to make a mistake which I was able to correct during the
release
without major issue, I think the same issue is behind the release of 2 bogus versions
(2.4.1 and 2.4.2)
There is another issue, users who want to mix and match applications to build their own
wiki are
faced with a set of version numbers and no way to know what is compatible with what. A
user who I
spoke with last night had this very problem. We could publish a compatibility matrix but
if we were
to show all the versions a given application is compatible with, that would require
testing each
application version against each core version and I think we need to concentrate on
testing what
gets released in XE.
Both of these problems would be fixed if version numbers were synchronized and everything
was
branched for a release. Relevant questions which come to mind are "do we need the
capability to
release applications at separate times?" and "is there no way to do that with
synchronized version
numbers?"
Am I missing any other reasons?
Should this not become a proposal?
Caleb
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
6:59 p.m.
Hi,
Alex Busenius wrote:
I'm totally +1 on synchronizing version numbers,
this has absolutely no
disadvantages vs. the current situation (we are already always releasing
the apps together with the core), but makes it much easier to release
and to use.
Alex
Perhaps this is a silly question but, please, as an user, I would like
to fully understand what does synchronizing version numbers mean. Does
it mean that when XE 2.5 is release, we'll have, for instance,
Administration Application 2.5? And, all application compatible with XE
2.5 will have the same minor.major version, 2.5?
Thanks!
Ricardo
--
Ricardo Rodríguez
CTO
eBioTIC.
Life Sciences, Data Modeling and Information Management Systems
8:06 p.m.
Yes.
Alex
On 10/06/2010 06:59 PM, [Ricardo Rodriguez] eBioTIC. wrote:
Hi,
Alex Busenius wrote:
I'm totally +1 on synchronizing version
numbers, this has absolutely no
disadvantages vs. the current situation (we are already always releasing
the apps together with the core), but makes it much easier to release
and to use.
Alex
Perhaps this is a silly question but, please, as an user, I would like
to fully understand what does synchronizing version numbers mean. Does
it mean that when XE 2.5 is release, we'll have, for instance,
Administration Application 2.5? And, all application compatible with XE
2.5 will have the same minor.major version, 2.5?
Thanks!
Ricardo
10:49 p.m.
Thanks.
Alex Busenius wrote:
Yes.
And being this way, we'll have a different xar for each application for
each release of XE even though it has not changed. Don't be possible to
implement some kind of "compatibility" table within XE? I don't know if
I'm asking for something difficult or very difficult. I'm sure it is not
easy: in that case, it would be already done!
So, be charible with this proposal:
1. Each application will have its own rhythm of release; at least major
release. I don't understand why an application that is not evolving as
quickly like the core, XE, will have to synchronize its release number
with it. Or perhaps it is a so well designed application that don't need
the same number of releases. Major release could represent changes in
the technology that makes incompatible
2. XE will be in charge of detecting attempts of installing incompatible
software. And each application will be in charge of cross-test its
compatibility with other software already installed in XE.
3. xwiki.org will maintain that compatibility matrix. And testers must
be identify within the XWiki community to make all this cross-testing
possible. Perhaps not with all the released XE versions and all
application releases, but perhaps the last two of three of them. I
think, nothing new, I know, that the update process is too hard for
"regular users" or even "regular administrators" and is preventing
many
users to update its XWiki software more frequently.
I use software from some other Open Source "modular" projects. Perhaps R
(from The R Foundation for Statistical Computing), Thunderbird, Firefox
and R are the best examples I know of a core and a constellations of
modules. The core is in charge of rejecting, or at least warning about,
the installation of incompatible software. I don't know the mechanism
behind the scene, but if we all depict a great future for XWiki where
dozens (at least!) of applications will be developed in its framework, I
think that we need such a kind of "automatic" mechanism that, at least,
prevents the load of incompatible applications or plugins in a core XE
installation.
Thanks!
Ricardo
--
Ricardo Rodríguez
CTO
eBioTIC.
Life Sciences, Data Modeling and Information Management Systems
7 Oct
7 Oct
11:01 a.m.
On 10/06/2010 04:49 PM, [Ricardo Rodriguez] eBioTIC. wrote:
Thanks.
Alex Busenius wrote:
This is a very interesting idea and if done correctly could be a big benefit. In Firefox,
it is
largely left up to the extension developers to guess how long their extension will remain
compatible. To fix this problem we would have to introduce a mechanism for each API
function to
promise that the function will remain until a given version number. If every API function
were
annotated with such numbers, then for a developer to determine how long their application
is
expected to be compatible would be a trivial task which could even be handled by static
code analysis.
Definitely something to think about as the extension manager is moving nearer to
completion.
Yes.
And being this way, we'll have a different xar for each application for
each release of XE even though it has not changed. Don't be possible to
implement some kind of "compatibility" table within XE? I don't know if
I'm asking for something difficult or very difficult. I'm sure it is not
easy: in that case, it would be already done!
So, be charible with this proposal:
1. Each application will have its own rhythm of release; at least major
release. I don't understand why an application that is not evolving as
quickly like the core, XE, will have to synchronize its release number
with it. Or perhaps it is a so well designed application that don't need
the same number of releases. Major release could represent changes in
the technology that makes incompatible
2. XE will be in charge of detecting attempts of installing incompatible
software. And each application will be in charge of cross-test its
compatibility with other software already installed in XE.
3. xwiki.org will maintain that compatibility matrix. And testers must
be identify within the XWiki community to make all this cross-testing
possible. Perhaps not with all the released XE versions and all
application releases, but perhaps the last two of three of them. I
think, nothing new, I know, that the update process is too hard for
"regular users" or even "regular administrators" and is preventing
many
users to update its XWiki software more frequently.
This is where things get difficult, IMO we need to concentrate on testing of the code
which is
released in XEnterprise.
I use software from some other Open Source "modular" projects. Perhaps R
(from The R Foundation for Statistical Computing), Thunderbird, Firefox
and R are the best examples I know of a core and a constellations of
modules. The core is in charge of rejecting, or at least warning about,
the installation of incompatible software. I don't know the mechanism
behind the scene, but if we all depict a great future for XWiki where
dozens (at least!) of applications will be developed in its framework, I
think that we need such a kind of "automatic" mechanism that, at least,
prevents the load of incompatible applications or plugins in a core XE
installation.
Thanks!
Ricardo
2:20 p.m.
On 10/06/2010 10:49 PM, [Ricardo Rodriguez] eBioTIC. wrote:
Thanks.
Alex Busenius wrote:
Yes, some apps that didn't change will be just renamed, but so what?
Actually, many well-known large software packages (e.g. KDE) are doing
it exactly like this.
Besides, a compatibility matrix would work as well with the synchronized
versions.
Yes.
And being this way, we'll have a different xar for each application for
each release of XE even though it has not changed. Don't be possible to
implement some kind of "compatibility" table within XE? I don't know if
I'm asking for something difficult or very difficult. I'm sure it is not
easy: in that case, it would be already done!
So, be charible with this proposal:
1. Each application will have its own rhythm of release; at least major
release. I don't understand why an application that is not evolving as
quickly like the core, XE, will have to synchronize its release number
with it. Or perhaps it is a so well designed application that don't need
the same number of releases. Major release could represent changes in
the technology that makes incompatible
Synchronization will make it easier to choose compatible packages. You
shouldn't need to think about versions, unless you are an adventurous
user and want to mix them, just take the next x.y.* for everything and
it will work for sure.
Thanks,
Alex
2. XE will be in charge of detecting attempts of
installing incompatible
software. And each application will be in charge of cross-test its
compatibility with other software already installed in XE.
3. xwiki.org will maintain that compatibility matrix. And testers must
be identify within the XWiki community to make all this cross-testing
possible. Perhaps not with all the released XE versions and all
application releases, but perhaps the last two of three of them. I
think, nothing new, I know, that the update process is too hard for
"regular users" or even "regular administrators" and is preventing
many
users to update its XWiki software more frequently.
I use software from some other Open Source "modular" projects. Perhaps R
(from The R Foundation for Statistical Computing), Thunderbird, Firefox
and R are the best examples I know of a core and a constellations of
modules. The core is in charge of rejecting, or at least warning about,
the installation of incompatible software. I don't know the mechanism
behind the scene, but if we all depict a great future for XWiki where
dozens (at least!) of applications will be developed in its framework, I
think that we need such a kind of "automatic" mechanism that, at least,
prevents the load of incompatible applications or plugins in a core XE
installation.
Thanks!
Ricardo
12:37 a.m.
On 10/06/2010 05:16 PM, Alex Busenius wrote:
I'm totally +1 on synchronizing version numbers,
this has absolutely no
disadvantages vs. the current situation (we are already always releasing
the apps together with the core), but makes it much easier to release
and to use.
Alex
I think that this is a very good idea. Personally I am confused too with
the current versioning scheme.
In order to maintain a certain degree of freedom for making application
evolve independently in the timeframe of a new XE release, we can adopt
a versioning scheme like:
XE Appliaction version = XEmajor.XEminor.XEpatchlevel.applicationversion
where XEmajor.XEminor.XEpatchlevel should always match the target XE
release where the application can be installed. applicationversion is an
additional number for making new releases of the application
independently of XE.
At each XE release every application will have a version bump to match
the new XE version, no matter if there are acutal changes in the
application (i.e., XE is branched with all its applications).
The previous versioning scheme can be a bit ugly in the case where
XEpatchlevel == 0 and applicationversion > 0 (e.g., Administration
Application 2.5.0.4 -> 5th release of the Administration application
compatible with XE 2.5 before that XE 2.5.1 or 2.6 is released)
But the invariant will always be: the first 3 components of the
application version will tell the user what is the XE version it is
compatible with.
This convention can also be enforced to 3rd party applications.
-Fabio
On 10/06/2010 02:28 PM, Caleb James DeLisle wrote:
I have been observing problems with the
versioning scheme which we are using.
Because applications are not branched along with core, when a bugfix version of a stable
branch is
released, new versions of applications are typically pulled in. This means that
`experimental' code
is being introduced into a `stable' branch in a bugfix version. This is not the path
I would choose
but more importantly we can't honestly say that our code goes through a
milestone/release candidate
verification process if some of the code is allowed to bypass it.
This situation has caused me to make a mistake which I was able to correct during the
release
without major issue, I think the same issue is behind the release of 2 bogus versions
(2.4.1 and 2.4.2)
There is another issue, users who want to mix and match applications to build their own
wiki are
faced with a set of version numbers and no way to know what is compatible with what. A
user who I
spoke with last night had this very problem. We could publish a compatibility matrix but
if we were
to show all the versions a given application is compatible with, that would require
testing each
application version against each core version and I think we need to concentrate on
testing what
gets released in XE.
Both of these problems would be fixed if version numbers were synchronized and everything
was
branched for a release. Relevant questions which come to mind are "do we need the
capability to
release applications at separate times?" and "is there no way to do that with
synchronized version
numbers?"
Am I missing any other reasons?
Should this not become a proposal?
Caleb
_______________________________________________
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
12:28 p.m.
On 10/07/2010 12:37 AM, Fabio Mancinelli wrote:
This convention can also be enforced to 3rd party
applications.
How? Force application contributors to re-publish their applications
every 2 weeks?
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
1:53 p.m.
On 10/07/2010 12:28 PM, Sergiu Dumitriu wrote:
On 10/07/2010 12:37 AM, Fabio Mancinelli wrote:
Of course :)
Just kidding... Right, this is not really feasible.
What about the convention applied only in the context of XWiki ecosystem?
-Fabio
This convention can also be enforced to 3rd party
applications.
How? Force application contributors to re-publish their applications
every 2 weeks?
9:24 a.m.
On 10/06/2010 03:28 PM, Caleb James DeLisle wrote:
I have been observing problems with the versioning
scheme which we are using.
Because applications are not branched along with core,
when a bugfix version of a stable branch is
released, new versions of applications are typically pulled in.
I'm not sure what you mean by "typically" here but I don't see the need
to automatically release an application whenever a bug fix release of XE
is made and I don't think our release managers do this. If an
application has bug fixes too and these bug fixes are compatible with
the bug fix release of XE then yes, otherwise the application needs a
branch.
This means that `experimental' code
is being introduced into a `stable' branch in a bugfix version.
That's not true. When you commit to an application you have to check
which versions of XE depend on it and if your changes are not compatible
with all of them then you have to make a branch.
I'm not convinced that synchronizing version numbers is a good idea. I'm
-0 for now.
Thanks,
Marius
This is not the path I would choose
but more importantly we can't honestly say that our code goes through a
milestone/release candidate
verification process if some of the code is allowed to bypass it.
This situation has caused me to make a mistake which I was able to correct during the
release
without major issue, I think the same issue is behind the release of 2 bogus versions
(2.4.1 and 2.4.2)
There is another issue, users who want to mix and match applications to build their own
wiki are
faced with a set of version numbers and no way to know what is compatible with what. A
user who I
spoke with last night had this very problem. We could publish a compatibility matrix but
if we were
to show all the versions a given application is compatible with, that would require
testing each
application version against each core version and I think we need to concentrate on
testing what
gets released in XE.
Both of these problems would be fixed if version numbers were synchronized and everything
was
branched for a release. Relevant questions which come to mind are "do we need the
capability to
release applications at separate times?" and "is there no way to do that with
synchronized version
numbers?"
Am I missing any other reasons?
Should this not become a proposal?
Caleb
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
10:51 a.m.
On 10/07/2010 03:24 AM, Marius Dumitru Florea wrote:
If the changes appear to be comparable then they should go from commit to release without
any
further testing, milestones or release candidates?
On 10/06/2010 03:28 PM, Caleb James DeLisle wrote:
Let's take for example the administration application which is included in each
release of enterprise.
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.4/pom… <--
v1.37
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.4.1/p… <--
v1.38
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.4.2/p… <--
v1.39
in v2.3
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.3/pom… <--
v1.33
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.3.1/p… <--
v1.34
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.3.2/p… <--
v1.34 with a
comment above that 1.35 is incompatible.
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2/pom… <--
v1.26
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.1/p… <--
v1.27
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.2/p… <--
v1.28
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.3/p… <--
v1.29
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.4/p… <--
v1.30
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.5/p… <--
v1.32
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.6/p… <--
v1.33
So in the last three versions, every time except for 1, this was the practice.
I have been observing problems with the
versioning scheme which we are using.
Because applications are not branched along with
core, when a bugfix version of a stable branch is
released, new versions of applications are typically pulled in.
I'm not sure what you mean by "typically" here but I don't see the need
to automatically release an application whenever a bug fix release of XE
is made and I don't think our release managers do this. If an
application has bug fixes too and these bug fixes are compatible with
the bug fix release of XE then yes, otherwise the application needs a
branch.
Branching to keep bug fixes to backport separate from regular development is a good idea,
but in
http://svn.xwiki.org/svnroot/xwiki/platform/xwiki-applications/branches/ I only see 4
branches have
ever been made.
This means that `experimental' code
is being introduced into a `stable' branch in a bugfix version.
That's not true. When you commit to an application you have to check
which versions of XE depend on it and if your changes are not compatible with all of them then you have to make a branch.
I'm not convinced that synchronizing version numbers is a good idea. I'm
-0 for now.
Thanks,
Marius
This is not the path I would choose
but more importantly we can't honestly say that our code goes through a
milestone/release candidate
verification process if some of the code is allowed to bypass it.
This situation has caused me to make a mistake which I was able to correct during the
release
without major issue, I think the same issue is behind the release of 2 bogus versions
(2.4.1 and 2.4.2)
There is another issue, users who want to mix and match applications to build their own
wiki are
faced with a set of version numbers and no way to know what is compatible with what. A
user who I
spoke with last night had this very problem. We could publish a compatibility matrix but
if we were
to show all the versions a given application is compatible with, that would require
testing each
application version against each core version and I think we need to concentrate on
testing what
gets released in XE.
Both of these problems would be fixed if version numbers were synchronized and everything
was
branched for a release. Relevant questions which come to mind are "do we need the
capability to
release applications at separate times?" and "is there no way to do that with
synchronized version
numbers?"
Am I missing any other reasons?
Should this not become a proposal?
Caleb
_______________________________________________
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
11:23 a.m.
On 10/07/2010 11:51 AM, Caleb James DeLisle wrote:
On 10/07/2010 03:24 AM, Marius Dumitru Florea wrote:
/platform/applications/administration$ svn log -r 30000:head
shows that there were bug fixes in all these releases of the
administration application (so no empty release) which means they were
rightfully included in the corresponding XE bug fix releases. It was the
responsibility of those who made the bug fixes to check if they were
compatible with the XE versions depending on it.
Thanks,
Marius
On 10/06/2010 03:28 PM, Caleb James DeLisle
wrote:
Let's take for example the administration application which is included in each
release of enterprise.
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.4/pom…
v1.37
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.4.1/p…
v1.38
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.4.2/p…
v1.39
in v2.3 I have been observing problems with the
versioning scheme which we are using.
Because applications are not branched along with
core, when a bugfix version of a stable branch is
released, new versions of applications are typically pulled in.
I'm not sure what you mean by "typically" here but I don't see the
need
to automatically release an application whenever a bug fix release of XE
is made and I don't think our release managers do this.
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.3/pom…
v1.33
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.3.1/p…
v1.34
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.3.2/p…
v1.34 with a
comment above that 1.35 is incompatible.
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2/pom…
v1.26
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.1/p…
v1.27
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.2/p…
v1.28
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.3/p…
v1.29
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.4/p…
v1.30
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.5/p…
v1.32
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.6/p…
v1.33
So in the last three versions, every time except for 1, this was the practice.
If the changes appear to be comparable then they should go from commit to release without
any
further testing, milestones or release candidates?
If an
application has bug fixes too and these bug fixes are compatible with
the bug fix release of XE then yes, otherwise the application needs a
branch.
Branching to keep bug fixes to backport separate from regular development is a good idea,
but in
http://svn.xwiki.org/svnroot/xwiki/platform/xwiki-applications/branches/ I only see 4
branches have
ever been made.
This means that `experimental' code
is being introduced into a `stable' branch in a bugfix version.
That's not true. When you commit to an application you have to check
which versions of XE depend on it and if your changes are not compatible with all of them then you have to make a branch.
I'm not convinced that synchronizing version numbers is a good idea. I'm
-0 for now.
Thanks,
Marius
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs This is not the path I would choose
but more importantly we can't honestly say that our code goes through a
milestone/release candidate
verification process if some of the code is allowed to bypass it.
This situation has caused me to make a mistake which I was able to correct during the
release
without major issue, I think the same issue is behind the release of 2 bogus versions
(2.4.1 and 2.4.2)
There is another issue, users who want to mix and match applications to build their own
wiki are
faced with a set of version numbers and no way to know what is compatible with what. A
user who I
spoke with last night had this very problem. We could publish a compatibility matrix but
if we were
to show all the versions a given application is compatible with, that would require
testing each
application version against each core version and I think we need to concentrate on
testing what
gets released in XE.
Both of these problems would be fixed if version numbers were synchronized and everything
was
branched for a release. Relevant questions which come to mind are "do we need the
capability to
release applications at separate times?" and "is there no way to do that with
synchronized version
numbers?"
Am I missing any other reasons?
Should this not become a proposal?
Caleb
_______________________________________________
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
11:35 a.m.
On 10/07/2010 05:23 AM, Marius Dumitru Florea wrote:
On 10/07/2010 11:51 AM, Caleb James DeLisle wrote:
Are you saying that it's okay for application changes which don't appear to be
incompatible to go
from commit to release in a matter of a couple of days without any milestones or release
candidates?
On 10/07/2010 03:24 AM, Marius Dumitru Florea wrote:
/platform/applications/administration$ svn log -r 30000:head
shows that there were bug fixes in all these releases of the
administration application (so no empty release) which means they were
rightfully included in the corresponding XE bug fix releases. It was the
responsibility of those who made the bug fixes to check if they were
compatible with the XE versions depending on it. On 10/06/2010 03:28 PM, Caleb James DeLisle
wrote:
Let's take for example the administration application which is included in each
release of enterprise.
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.4/pom…
v1.37
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.4.1/p…
v1.38
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.4.2/p…
v1.39
in v2.3 I have been observing problems with the
versioning scheme which we are using.
Because applications are not branched along with
core, when a bugfix version of a stable branch is
released, new versions of applications are typically pulled in.
I'm not sure what you mean by "typically" here but I don't see the
need
to automatically release an application whenever a bug fix release of XE
is made and I don't think our release managers do this.
Thanks,
Marius
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.3/pom…
v1.33
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.3.1/p…
v1.34
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.3.2/p…
v1.34 with a
comment above that 1.35 is incompatible.
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2/pom…
v1.26
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.1/p…
v1.27
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.2/p…
v1.28
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.3/p…
v1.29
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.4/p…
v1.30
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.5/p…
v1.32
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.6/p…
v1.33
So in the last three versions, every time except for 1, this was the practice.
If the changes appear to be comparable then they should go from commit to release without
any
further testing, milestones or release candidates?
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
If an
application has bug fixes too and these bug fixes are compatible with
the bug fix release of XE then yes, otherwise the application needs a
branch.
Branching to keep bug fixes to backport separate from regular development is a good idea,
but in
http://svn.xwiki.org/svnroot/xwiki/platform/xwiki-applications/branches/ I only see 4
branches have
ever been made.
This means that `experimental' code
is being introduced into a `stable' branch in a bugfix version.
That's not true. When you commit to an application you have to check
which versions of XE depend on it and if your changes are not compatible with all of them then you have to make a branch.
I'm not convinced that synchronizing version numbers is a good idea. I'm
-0 for now.
Thanks,
Marius
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs This is not the path I would choose
but more importantly we can't honestly say that our code goes through a
milestone/release candidate
verification process if some of the code is allowed to bypass it.
This situation has caused me to make a mistake which I was able to correct during the
release
without major issue, I think the same issue is behind the release of 2 bogus versions
(2.4.1 and 2.4.2)
There is another issue, users who want to mix and match applications to build their own
wiki are
faced with a set of version numbers and no way to know what is compatible with what. A
user who I
spoke with last night had this very problem. We could publish a compatibility matrix but
if we were
to show all the versions a given application is compatible with, that would require
testing each
application version against each core version and I think we need to concentrate on
testing what
gets released in XE.
Both of these problems would be fixed if version numbers were synchronized and everything
was
branched for a release. Relevant questions which come to mind are "do we need the
capability to
release applications at separate times?" and "is there no way to do that with
synchronized version
numbers?"
Am I missing any other reasons?
Should this not become a proposal?
Caleb
_______________________________________________
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
12:01 p.m.
On 10/07/2010 12:35 PM, Caleb James DeLisle wrote:
On 10/07/2010 05:23 AM, Marius Dumitru Florea wrote:
On 10/07/2010 11:51 AM, Caleb James DeLisle
wrote:
On 10/07/2010 03:24 AM, Marius Dumitru Florea wrote:
/platform/applications/administration$ svn log -r 30000:head
shows that there were bug fixes in all these releases of the
administration application (so no empty release) which means they were
rightfully included in the corresponding XE bug fix releases. It was the
responsibility of those who made the bug fixes to check if they were
compatible with the XE versions depending on it. On 10/06/2010 03:28 PM, Caleb James DeLisle
wrote:
> I have been observing problems with the versioning scheme which we are using.
>
> Because applications are not branched along with core, when a bugfix version of a
stable branch is
> released, new versions of applications are typically pulled in.
I'm not sure what you mean by "typically" here but I don't see the
need
to automatically release an application whenever a bug fix release of XE
is made and I don't think our release managers do this.
Let's take for example the administration application which is included in each
release of enterprise.
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.4/pom…
v1.37
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.4.1/p…
v1.38
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.4.2/p…
v1.39
in v2.3 Are you saying that it's okay for application
changes which don't appear to be incompatible to go
from commit to release in a matter of a couple of days without any milestones or release
candidates?
No, I'm referring only to bug fixes. For new application features or
improvements a branch is needed. The bug fix XE will depend on the
branch snapshot and trunk XE will depend on the application trunk
snapshot, which includes the new features and improvements.
Marius
Thanks,
Marius
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.3/pom…
v1.33
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.3.1/p…
v1.34
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.3.2/p…
v1.34 with a
comment above that 1.35 is incompatible.
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2/pom…
v1.26
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.1/p…
v1.27
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.2/p…
v1.28
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.3/p…
v1.29
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.4/p…
v1.30
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.5/p…
v1.32
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.6/p…
v1.33
So in the last three versions, every time except for 1, this was the practice.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
If an
application has bug fixes too and these bug fixes are compatible with
the bug fix release of XE then yes, otherwise the application needs a
branch.
Branching to keep bug fixes to backport separate from regular development is a good idea,
but in
http://svn.xwiki.org/svnroot/xwiki/platform/xwiki-applications/branches/ I only see 4
branches have
ever been made.
> This means that `experimental' code
> is being introduced into a `stable' branch in a bugfix version.
That's not true. When you commit to an application you have to check
which versions of XE depend on it and if your changes are not compatible
If the changes appear to be comparable then they should go from commit to release without
any
further testing, milestones or release candidates?
with all of them then you have to make a branch.
I'm not convinced that synchronizing version numbers is a good idea. I'm
-0 for now.
Thanks,
Marius
> This is not the path I would choose
> but more importantly we can't honestly say that our code goes through a
milestone/release candidate
> verification process if some of the code is allowed to bypass it.
> This situation has caused me to make a mistake which I was able to correct during the
release
> without major issue, I think the same issue is behind the release of 2 bogus versions
(2.4.1 and 2.4.2)
>
> There is another issue, users who want to mix and match applications to build their
own wiki are
> faced with a set of version numbers and no way to know what is compatible with what.
A user who I
> spoke with last night had this very problem. We could publish a compatibility matrix
but if we were
> to show all the versions a given application is compatible with, that would require
testing each
> application version against each core version and I think we need to concentrate on
testing what
> gets released in XE.
>
> Both of these problems would be fixed if version numbers were synchronized and
everything was
> branched for a release. Relevant questions which come to mind are "do we need
the capability to
> release applications at separate times?" and "is there no way to do that
with synchronized version
> numbers?"
>
> Am I missing any other reasons?
> Should this not become a proposal?
>
> Caleb
>
> _______________________________________________
> 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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
12:25 p.m.
On 10/07/2010 06:01 AM, Marius Dumitru Florea wrote:
On 10/07/2010 12:35 PM, Caleb James DeLisle wrote:
You mean the new changes go into the branch or the safe code goes into the branch and the
new
changes go on the trunk?
On 10/07/2010 05:23 AM, Marius Dumitru Florea wrote:
On 10/07/2010 11:51 AM, Caleb James DeLisle
wrote:
On 10/07/2010 03:24 AM, Marius Dumitru Florea wrote:
> On 10/06/2010 03:28 PM, Caleb James DeLisle wrote:
>> I have been observing problems with the versioning scheme which we are using.
>>
>
>> Because applications are not branched along with core, when a bugfix version of a
stable branch is
>> released, new versions of applications are typically pulled in.
>
> I'm not sure what you mean by "typically" here but I don't see the
need
> to automatically release an application whenever a bug fix release of XE
> is made and I don't think our release managers do this.
Let's take for example the administration application which is included in each
release of enterprise.
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.4/pom…
v1.37
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.4.1/p…
v1.38
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.4.2/p…
v1.39
in v2.3
/platform/applications/administration$ svn log -r 30000:head
shows that there were bug fixes in all these releases of the
administration application (so no empty release) which means they were
rightfully included in the corresponding XE bug fix releases. It was the
responsibility of those who made the bug fixes to check if they were
compatible with the XE versions depending on it. Are you saying that it's okay for application
changes which don't appear to be incompatible to go
from commit to release in a matter of a couple of days without any milestones or release
candidates?
No, I'm referring only to bug fixes. For new application features or
improvements a branch is needed. The bug fix XE will depend on the
branch snapshot and trunk XE will depend on the application trunk
snapshot, which includes the new features and improvements.
Marius
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Thanks,
Marius
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.3/pom…
v1.33
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.3.1/p…
v1.34
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.3.2/p…
v1.34 with a
comment above that 1.35 is incompatible.
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2/pom…
v1.26
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.1/p…
v1.27
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.2/p…
v1.28
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.3/p…
v1.29
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.4/p…
v1.30
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.5/p…
v1.32
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.6/p…
v1.33
So in the last three versions, every time except for 1, this was the practice.
> If an
> application has bug fixes too and these bug fixes are compatible with
> the bug fix release of XE then yes, otherwise the application needs a
> branch.
Branching to keep bug fixes to backport separate from regular development is a good idea,
but in
http://svn.xwiki.org/svnroot/xwiki/platform/xwiki-applications/branches/ I only see 4
branches have
ever been made.
>
>> This means that `experimental' code
>> is being introduced into a `stable' branch in a bugfix version.
>
> That's not true. When you commit to an application you have to check
> which versions of XE depend on it and if your changes are not compatible
If the changes appear to be comparable then they should go from commit to release without
any
further testing, milestones or release candidates?
> with all of them then you have to make a branch.
>
> I'm not convinced that synchronizing version numbers is a good idea. I'm
> -0 for now.
>
> Thanks,
> Marius
>
>> This is not the path I would choose
>> but more importantly we can't honestly say that our code goes through a
milestone/release candidate
>> verification process if some of the code is allowed to bypass it.
>> This situation has caused me to make a mistake which I was able to correct during
the release
>> without major issue, I think the same issue is behind the release of 2 bogus
versions (2.4.1 and 2.4.2)
>>
>> There is another issue, users who want to mix and match applications to build
their own wiki are
>> faced with a set of version numbers and no way to know what is compatible with
what. A user who I
>> spoke with last night had this very problem. We could publish a compatibility
matrix but if we were
>> to show all the versions a given application is compatible with, that would
require testing each
>> application version against each core version and I think we need to concentrate
on testing what
>> gets released in XE.
>>
>> Both of these problems would be fixed if version numbers were synchronized and
everything was
>> branched for a release. Relevant questions which come to mind are "do we
need the capability to
>> release applications at separate times?" and "is there no way to do
that with synchronized version
>> numbers?"
>>
>> Am I missing any other reasons?
>> Should this not become a proposal?
>>
>> Caleb
>>
>> _______________________________________________
>> 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
>
_______________________________________________
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
12:44 p.m.
On 10/07/2010 01:25 PM, Caleb James DeLisle wrote:
On 10/07/2010 06:01 AM, Marius Dumitru Florea wrote:
On 10/07/2010 12:35 PM, Caleb James DeLisle
wrote:
On 10/07/2010 05:23 AM, Marius Dumitru Florea wrote:
On 10/07/2010 11:51 AM, Caleb James DeLisle
wrote:
>
>
> On 10/07/2010 03:24 AM, Marius Dumitru Florea wrote:
>> On 10/06/2010 03:28 PM, Caleb James DeLisle wrote:
>>> I have been observing problems with the versioning scheme which we are
using.
>>>
>>
>>> Because applications are not branched along with core, when a bugfix version
of a stable branch is
>>> released, new versions of applications are typically pulled in.
>>
>> I'm not sure what you mean by "typically" here but I don't see
the need
>> to automatically release an application whenever a bug fix release of XE
>> is made and I don't think our release managers do this.
>
> Let's take for example the administration application which is included in each
release of enterprise.
> http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.4/pom…
v1.37
>
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.4.1/p…
v1.38
>
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.4.2/p…
v1.39
> in v2.3
/platform/applications/administration$ svn log -r 30000:head
shows that there were bug fixes in all these releases of the
administration application (so no empty release) which means they were
rightfully included in the corresponding XE bug fix releases. It was the
responsibility of those who made the bug fixes to check if they were
compatible with the XE versions depending on it.
Are you saying that it's okay for application
changes which don't appear to be incompatible to go
from commit to release in a matter of a couple of days without any milestones or release
candidates?
No, I'm referring only to bug fixes. For new application features or
improvements a branch is needed. You mean the new changes go into the branch or the
safe code goes into the branch and the new
changes go on the trunk?
Safe code goes into the branch, and new code goes into the trunk. Let's
take an example:
XE 2.5-SNAPSHOT (trunk) and XE 2.4-SNAPSHOT (branch, next 2.4.1) depend
on administration application 1.37-SNAPSHOT (trunk).
A bug if discovered in the administration. We want this bug fixed both
in XE 2.5 and XE 2.4.1 so we commit in the administration application
trunk (1.37-SNAPSHOT).
Someone wants to introduce a new feature in the administration
application. He creates a branch for the administration application:
1.37-SNAPSHOT trunk is copied into a branch and trunk version is
incremented to 1.38-SNAPSHOT. He then commits into 1.38-SNAPSHOT (trunk)
and updates XE 2.5-SNAPSHOT dependency on administration application to
1.38-SNAPSHOT.
At this point XE 2.4-SNAPSHOT depends on administration application
1.37-SNAPSHOT and XE 2.5-SNAPSHOT on 1.38-SNAPSHOT.
A new bug if discovered in the administration application and we want it
to be fixed both in XE 2.5 and XE 2.4.1. We commit the fix in
1.38-SNAPSHOT (trunk) and merge it in 1.37-SNAPSHOT (branch).
That's it.
Marius
The bug fix XE will depend on the
branch snapshot and trunk XE will depend on the application trunk
snapshot, which includes the new features and improvements.
Marius
_______________________________________________
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
Thanks,
Marius
> http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.3/pom…
v1.33
>
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.3.1/p…
v1.34
>
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.3.2/p…
v1.34 with a
> comment above that 1.35 is incompatible.
>
> http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2/pom…
v1.26
>
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.1/p…
v1.27
>
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.2/p…
v1.28
>
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.3/p…
v1.29
>
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.4/p…
v1.30
>
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.5/p…
v1.32
>
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.6/p…
v1.33
>
> So in the last three versions, every time except for 1, this was the practice.
>
>
>> If an
>> application has bug fixes too and these bug fixes are compatible with
>> the bug fix release of XE then yes, otherwise the application needs a
>> branch.
>
> Branching to keep bug fixes to backport separate from regular development is a good
idea, but in
> http://svn.xwiki.org/svnroot/xwiki/platform/xwiki-applications/branches/ I only see 4
branches have
> ever been made.
>
>>
>>> This means that `experimental' code
>>> is being introduced into a `stable' branch in a bugfix version.
>>
>> That's not true. When you commit to an application you have to check
>> which versions of XE depend on it and if your changes are not compatible
>
> If the changes appear to be comparable then they should go from commit to release
without any
> further testing, milestones or release candidates?
>
>> with all of them then you have to make a branch.
>>
>> I'm not convinced that synchronizing version numbers is a good idea. I'm
>> -0 for now.
>>
>> Thanks,
>> Marius
>>
>>> This is not the path I would choose
>>> but more importantly we can't honestly say that our code goes through a
milestone/release candidate
>>> verification process if some of the code is allowed to bypass it.
>>> This situation has caused me to make a mistake which I was able to correct
during the release
>>> without major issue, I think the same issue is behind the release of 2 bogus
versions (2.4.1 and 2.4.2)
>>>
>>> There is another issue, users who want to mix and match applications to build
their own wiki are
>>> faced with a set of version numbers and no way to know what is compatible
with what. A user who I
>>> spoke with last night had this very problem. We could publish a compatibility
matrix but if we were
>>> to show all the versions a given application is compatible with, that would
require testing each
>>> application version against each core version and I think we need to
concentrate on testing what
>>> gets released in XE.
>>>
>>> Both of these problems would be fixed if version numbers were synchronized
and everything was
>>> branched for a release. Relevant questions which come to mind are "do we
need the capability to
>>> release applications at separate times?" and "is there no way to do
that with synchronized version
>>> numbers?"
>>>
>>> Am I missing any other reasons?
>>> Should this not become a proposal?
>>>
>>> Caleb
>>>
>>> _______________________________________________
>>> 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
>>
>
> _______________________________________________
> 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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
12:56 p.m.
On 10/07/2010 06:44 AM, Marius Dumitru Florea wrote:
On 10/07/2010 01:25 PM, Caleb James DeLisle wrote:
I see, this seems right (apart from the fact that it is not practiced) the only question
which comes
up is if "1.37-SNAPSHOT trunk is copied into a branch and trunk version is
incremented to
1.38-SNAPSHOT" does then the 1.37-SNAPSHOT get incremented to 1.37.1-SNAPSHOT to tell
the world that
it is different from 1.37 the buggy version?
On 10/07/2010 06:01 AM, Marius Dumitru Florea wrote:
On 10/07/2010 12:35 PM, Caleb James DeLisle
wrote:
On 10/07/2010 05:23 AM, Marius Dumitru Florea wrote:
> On 10/07/2010 11:51 AM, Caleb James DeLisle wrote:
>>
>>
>> On 10/07/2010 03:24 AM, Marius Dumitru Florea wrote:
>>> On 10/06/2010 03:28 PM, Caleb James DeLisle wrote:
>>>> I have been observing problems with the versioning scheme which we are
using.
>>>>
>>>
>>>> Because applications are not branched along with core, when a bugfix
version of a stable branch is
>>>> released, new versions of applications are typically pulled in.
>>>
>>> I'm not sure what you mean by "typically" here but I don't
see the need
>>> to automatically release an application whenever a bug fix release of XE
>>> is made and I don't think our release managers do this.
>>
>> Let's take for example the administration application which is included in
each release of enterprise.
>>
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.4/pom…
v1.37
>>
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.4.1/p…
v1.38
>>
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.4.2/p…
v1.39
>> in v2.3
>
> /platform/applications/administration$ svn log -r 30000:head
>
> shows that there were bug fixes in all these releases of the
> administration application (so no empty release) which means they were
> rightfully included in the corresponding XE bug fix releases. It was the
> responsibility of those who made the bug fixes to check if they were
> compatible with the XE versions depending on it.
Are you saying that it's okay for application
changes which don't appear to be incompatible to go
from commit to release in a matter of a couple of days without any milestones or release
candidates?
No, I'm referring only to bug fixes. For new application features or
improvements a branch is needed. You mean the new changes go into the branch or
the safe code goes into the branch and the new
changes go on the trunk?
Safe code goes into the branch, and new code goes into the trunk. Let's
take an example:
XE 2.5-SNAPSHOT (trunk) and XE 2.4-SNAPSHOT (branch, next 2.4.1) depend
on administration application 1.37-SNAPSHOT (trunk).
A bug if discovered in the administration. We want this bug fixed both
in XE 2.5 and XE 2.4.1 so we commit in the administration application
trunk (1.37-SNAPSHOT).
Someone wants to introduce a new feature in the administration
application. He creates a branch for the administration application:
1.37-SNAPSHOT trunk is copied into a branch and trunk version is
incremented to 1.38-SNAPSHOT. He then commits into 1.38-SNAPSHOT (trunk)
and updates XE 2.5-SNAPSHOT dependency on administration application to
1.38-SNAPSHOT.
At this point XE 2.4-SNAPSHOT depends on administration application
1.37-SNAPSHOT and XE 2.5-SNAPSHOT on 1.38-SNAPSHOT.
A new bug if discovered in the administration application and we want it
to be fixed both in XE 2.5 and XE 2.4.1. We commit the fix in
1.38-SNAPSHOT (trunk) and merge it in 1.37-SNAPSHOT (branch).
That's it.
Marius
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
The bug fix XE will depend on the
branch snapshot and trunk XE will depend on the application trunk
snapshot, which includes the new features and improvements.
Marius
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
>
> Thanks,
> Marius
>
>>
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.3/pom…
v1.33
>>
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.3.1/p…
v1.34
>>
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.3.2/p…
v1.34 with a
>> comment above that 1.35 is incompatible.
>>
>>
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2/pom…
v1.26
>>
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.1/p…
v1.27
>>
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.2/p…
v1.28
>>
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.3/p…
v1.29
>>
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.4/p…
v1.30
>>
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.5/p…
v1.32
>>
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.6/p…
v1.33
>>
>> So in the last three versions, every time except for 1, this was the practice.
>>
>>
>>> If an
>>> application has bug fixes too and these bug fixes are compatible with
>>> the bug fix release of XE then yes, otherwise the application needs a
>>> branch.
>>
>> Branching to keep bug fixes to backport separate from regular development is a
good idea, but in
>> http://svn.xwiki.org/svnroot/xwiki/platform/xwiki-applications/branches/ I only
see 4 branches have
>> ever been made.
>>
>>>
>>>> This means that `experimental' code
>>>> is being introduced into a `stable' branch in a bugfix version.
>>>
>>> That's not true. When you commit to an application you have to check
>>> which versions of XE depend on it and if your changes are not compatible
>>
>> If the changes appear to be comparable then they should go from commit to release
without any
>> further testing, milestones or release candidates?
>>
>>> with all of them then you have to make a branch.
>>>
>>> I'm not convinced that synchronizing version numbers is a good idea.
I'm
>>> -0 for now.
>>>
>>> Thanks,
>>> Marius
>>>
>>>> This is not the path I would choose
>>>> but more importantly we can't honestly say that our code goes through
a milestone/release candidate
>>>> verification process if some of the code is allowed to bypass it.
>>>> This situation has caused me to make a mistake which I was able to
correct during the release
>>>> without major issue, I think the same issue is behind the release of 2
bogus versions (2.4.1 and 2.4.2)
>>>>
>>>> There is another issue, users who want to mix and match applications to
build their own wiki are
>>>> faced with a set of version numbers and no way to know what is compatible
with what. A user who I
>>>> spoke with last night had this very problem. We could publish a
compatibility matrix but if we were
>>>> to show all the versions a given application is compatible with, that
would require testing each
>>>> application version against each core version and I think we need to
concentrate on testing what
>>>> gets released in XE.
>>>>
>>>> Both of these problems would be fixed if version numbers were
synchronized and everything was
>>>> branched for a release. Relevant questions which come to mind are
"do we need the capability to
>>>> release applications at separate times?" and "is there no way
to do that with synchronized version
>>>> numbers?"
>>>>
>>>> Am I missing any other reasons?
>>>> Should this not become a proposal?
>>>>
>>>> Caleb
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>
>> _______________________________________________
>> 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
>
_______________________________________________
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
1:42 p.m.
On Thu, Oct 7, 2010 at 12:56, Caleb James DeLisle
<calebdelisle(a)lavabit.com> wrote:
--
Thomas Mortagne
On 10/07/2010 06:44 AM, Marius Dumitru Florea wrote:
No need, having a branch already make it "different from 1.37 the
buggy version". It's exactly the same for XE.
On 10/07/2010 01:25 PM, Caleb James DeLisle
wrote:
I see, this seems right (apart from the fact that it is not practiced) the only question
which comes
up is if "1.37-SNAPSHOT trunk is copied into a branch and trunk version is
incremented to
1.38-SNAPSHOT" does then the 1.37-SNAPSHOT get incremented to 1.37.1-SNAPSHOT to
tell the world that
it is different from 1.37 the buggy version?
On 10/07/2010 06:01 AM, Marius Dumitru Florea wrote:
On 10/07/2010 12:35 PM, Caleb James DeLisle
wrote:
>
>
> On 10/07/2010 05:23 AM, Marius Dumitru Florea wrote:
>> On 10/07/2010 11:51 AM, Caleb James DeLisle wrote:
>>>
>>>
>>> On 10/07/2010 03:24 AM, Marius Dumitru Florea wrote:
>>>> On 10/06/2010 03:28 PM, Caleb James DeLisle wrote:
>>>>> I have been observing problems with the versioning scheme which we
are using.
>>>>>
>>>>
>>>>> Because applications are not branched along with core, when a bugfix
version of a stable branch is
>>>>> released, new versions of applications are typically pulled in.
>>>>
>>>> I'm not sure what you mean by "typically" here but I
don't see the need
>>>> to automatically release an application whenever a bug fix release of XE
>>>> is made and I don't think our release managers do this.
>>>
>>> Let's take for example the administration application which is included
in each release of enterprise.
>>>
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.4/pom…
v1.37
>>>
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.4.1/p…
v1.38
>>>
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.4.2/p…
v1.39
>>> in v2.3
>>
>> /platform/applications/administration$ svn log -r 30000:head
>>
>> shows that there were bug fixes in all these releases of the
>> administration application (so no empty release) which means they were
>> rightfully included in the corresponding XE bug fix releases. It was the
>> responsibility of those who made the bug fixes to check if they were
>> compatible with the XE versions depending on it.
>
> Are you saying that it's okay for application changes which don't appear to
be incompatible to go
> from commit to release in a matter of a couple of days without any milestones or
release candidates?
No, I'm referring only to bug fixes. For new application features or
improvements a branch is needed.
You mean the new changes go into the branch or
the safe code goes into the branch and the new
changes go on the trunk?
Safe code goes into the branch, and new code goes into the trunk. Let's
take an example:
XE 2.5-SNAPSHOT (trunk) and XE 2.4-SNAPSHOT (branch, next 2.4.1) depend
on administration application 1.37-SNAPSHOT (trunk).
A bug if discovered in the administration. We want this bug fixed both
in XE 2.5 and XE 2.4.1 so we commit in the administration application
trunk (1.37-SNAPSHOT).
Someone wants to introduce a new feature in the administration
application. He creates a branch for the administration application:
1.37-SNAPSHOT trunk is copied into a branch and trunk version is
incremented to 1.38-SNAPSHOT. He then commits into 1.38-SNAPSHOT (trunk)
and updates XE 2.5-SNAPSHOT dependency on administration application to
1.38-SNAPSHOT.
At this point XE 2.4-SNAPSHOT depends on administration application
1.37-SNAPSHOT and XE 2.5-SNAPSHOT on 1.38-SNAPSHOT.
A new bug if discovered in the administration application and we want it
to be fixed both in XE 2.5 and XE 2.4.1. We commit the fix in
1.38-SNAPSHOT (trunk) and merge it in 1.37-SNAPSHOT (branch).
That's it.
Marius
_______________________________________________
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
The bug fix XE will depend on the
branch snapshot and trunk XE will depend on the application trunk
snapshot, which includes the new features and improvements.
Marius
>
>>
>> Thanks,
>> Marius
>>
>>>
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.3/pom…
v1.33
>>>
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.3.1/p…
v1.34
>>>
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.3.2/p…
v1.34 with a
>>> comment above that 1.35 is incompatible.
>>>
>>>
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2/pom…
v1.26
>>>
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.1/p…
v1.27
>>>
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.2/p…
v1.28
>>>
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.3/p…
v1.29
>>>
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.4/p…
v1.30
>>>
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.5/p…
v1.32
>>>
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.6/p…
v1.33
>>>
>>> So in the last three versions, every time except for 1, this was the
practice.
>>>
>>>
>>>> If an
>>>> application has bug fixes too and these bug fixes are compatible with
>>>> the bug fix release of XE then yes, otherwise the application needs a
>>>> branch.
>>>
>>> Branching to keep bug fixes to backport separate from regular development is
a good idea, but in
>>> http://svn.xwiki.org/svnroot/xwiki/platform/xwiki-applications/branches/ I
only see 4 branches have
>>> ever been made.
>>>
>>>>
>>>>> This means that `experimental' code
>>>>> is being introduced into a `stable' branch in a bugfix version.
>>>>
>>>> That's not true. When you commit to an application you have to check
>>>> which versions of XE depend on it and if your changes are not compatible
>>>
>>> If the changes appear to be comparable then they should go from commit to
release without any
>>> further testing, milestones or release candidates?
>>>
>>>> with all of them then you have to make a branch.
>>>>
>>>> I'm not convinced that synchronizing version numbers is a good idea.
I'm
>>>> -0 for now.
>>>>
>>>> Thanks,
>>>> Marius
>>>>
>>>>> This is not the path I would choose
>>>>> but more importantly we can't honestly say that our code goes
through a milestone/release candidate
>>>>> verification process if some of the code is allowed to bypass it.
>>>>> This situation has caused me to make a mistake which I was able to
correct during the release
>>>>> without major issue, I think the same issue is behind the release of
2 bogus versions (2.4.1 and 2.4.2)
>>>>>
>>>>> There is another issue, users who want to mix and match applications
to build their own wiki are
>>>>> faced with a set of version numbers and no way to know what is
compatible with what. A user who I
>>>>> spoke with last night had this very problem. We could publish a
compatibility matrix but if we were
>>>>> to show all the versions a given application is compatible with, that
would require testing each
>>>>> application version against each core version and I think we need to
concentrate on testing what
>>>>> gets released in XE.
>>>>>
>>>>> Both of these problems would be fixed if version numbers were
synchronized and everything was
>>>>> branched for a release. Relevant questions which come to mind are
"do we need the capability to
>>>>> release applications at separate times?" and "is there no
way to do that with synchronized version
>>>>> numbers?"
>>>>>
>>>>> Am I missing any other reasons?
>>>>> Should this not become a proposal?
>>>>>
>>>>> Caleb
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>
>>> _______________________________________________
>>> 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
>>
>
> _______________________________________________
> 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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
2:37 p.m.
On 10/07/2010 12:44 PM, Marius Dumitru Florea wrote:
On 10/07/2010 01:25 PM, Caleb James DeLisle wrote:
A few days ago I was told that in a similar case (a change that makes
administration application dependent on 2.5) the change should go to
1.37-SNAPSHOT trunk and add a version range to pom, signalizing
incompatibility. When someone wants to release 2.4.1, or fix a bug in
this application *he* will need to notice the version range and branch
1.36 to 1.36.1.
So... what is now the right way of dealing with such things? In
synchronized setting, the incompatible change would go to 2.5-SNAPSHOT
branch, which would already be there.
Thanks,
Alex
On 10/07/2010 06:01 AM, Marius Dumitru Florea wrote:
On 10/07/2010 12:35 PM, Caleb James DeLisle
wrote:
On 10/07/2010 05:23 AM, Marius Dumitru Florea wrote:
> On 10/07/2010 11:51 AM, Caleb James DeLisle wrote:
>>
>>
>> On 10/07/2010 03:24 AM, Marius Dumitru Florea wrote:
>>> On 10/06/2010 03:28 PM, Caleb James DeLisle wrote:
>>>> I have been observing problems with the versioning scheme which we are
using.
>>>>
>>>
>>>> Because applications are not branched along with core, when a bugfix
version of a stable branch is
>>>> released, new versions of applications are typically pulled in.
>>>
>>> I'm not sure what you mean by "typically" here but I don't
see the need
>>> to automatically release an application whenever a bug fix release of XE
>>> is made and I don't think our release managers do this.
>>
>> Let's take for example the administration application which is included in
each release of enterprise.
>>
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.4/pom…
v1.37
>>
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.4.1/p…
v1.38
>>
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.4.2/p…
v1.39
>> in v2.3
>
> /platform/applications/administration$ svn log -r 30000:head
>
> shows that there were bug fixes in all these releases of the
> administration application (so no empty release) which means they were
> rightfully included in the corresponding XE bug fix releases. It was the
> responsibility of those who made the bug fixes to check if they were
> compatible with the XE versions depending on it.
Are you saying that it's okay for application
changes which don't appear to be incompatible to go
from commit to release in a matter of a couple of days without any milestones or release
candidates?
No, I'm referring only to bug fixes. For new application features or
improvements a branch is needed. You mean the new changes go into the branch or
the safe code goes into the branch and the new
changes go on the trunk?
Safe code goes into the branch, and new code goes into the trunk. Let's
take an example:
XE 2.5-SNAPSHOT (trunk) and XE 2.4-SNAPSHOT (branch, next 2.4.1) depend
on administration application 1.37-SNAPSHOT (trunk).
A bug if discovered in the administration. We want this bug fixed both
in XE 2.5 and XE 2.4.1 so we commit in the administration application
trunk (1.37-SNAPSHOT).
Someone wants to introduce a new feature in the administration
application. He creates a branch for the administration application:
1.37-SNAPSHOT trunk is copied into a branch and trunk version is
incremented to 1.38-SNAPSHOT. He then commits into 1.38-SNAPSHOT (trunk)
and updates XE 2.5-SNAPSHOT dependency on administration application to
1.38-SNAPSHOT.
At this point XE 2.4-SNAPSHOT depends on
administration application
1.37-SNAPSHOT and XE 2.5-SNAPSHOT on 1.38-SNAPSHOT.
A new bug if discovered in the administration application and we want it
to be fixed both in XE 2.5 and XE 2.4.1. We commit the fix in
1.38-SNAPSHOT (trunk) and merge it in 1.37-SNAPSHOT (branch).
That's it.
Marius
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
The bug fix XE will depend on the
branch snapshot and trunk XE will depend on the application trunk
snapshot, which includes the new features and improvements.
Marius
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
>
> Thanks,
> Marius
>
>>
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.3/pom…
v1.33
>>
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.3.1/p…
v1.34
>>
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.3.2/p…
v1.34 with a
>> comment above that 1.35 is incompatible.
>>
>>
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2/pom…
v1.26
>>
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.1/p…
v1.27
>>
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.2/p…
v1.28
>>
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.3/p…
v1.29
>>
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.4/p…
v1.30
>>
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.5/p…
v1.32
>>
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.6/p…
v1.33
>>
>> So in the last three versions, every time except for 1, this was the practice.
>>
>>
>>> If an
>>> application has bug fixes too and these bug fixes are compatible with
>>> the bug fix release of XE then yes, otherwise the application needs a
>>> branch.
>>
>> Branching to keep bug fixes to backport separate from regular development is a
good idea, but in
>> http://svn.xwiki.org/svnroot/xwiki/platform/xwiki-applications/branches/ I only
see 4 branches have
>> ever been made.
>>
>>>
>>>> This means that `experimental' code
>>>> is being introduced into a `stable' branch in a bugfix version.
>>>
>>> That's not true. When you commit to an application you have to check
>>> which versions of XE depend on it and if your changes are not compatible
>>
>> If the changes appear to be comparable then they should go from commit to release
without any
>> further testing, milestones or release candidates?
>>
>>> with all of them then you have to make a branch.
>>>
>>> I'm not convinced that synchronizing version numbers is a good idea.
I'm
>>> -0 for now.
>>>
>>> Thanks,
>>> Marius
>>>
>>>> This is not the path I would choose
>>>> but more importantly we can't honestly say that our code goes through
a milestone/release candidate
>>>> verification process if some of the code is allowed to bypass it.
>>>> This situation has caused me to make a mistake which I was able to
correct during the release
>>>> without major issue, I think the same issue is behind the release of 2
bogus versions (2.4.1 and 2.4.2)
>>>>
>>>> There is another issue, users who want to mix and match applications to
build their own wiki are
>>>> faced with a set of version numbers and no way to know what is compatible
with what. A user who I
>>>> spoke with last night had this very problem. We could publish a
compatibility matrix but if we were
>>>> to show all the versions a given application is compatible with, that
would require testing each
>>>> application version against each core version and I think we need to
concentrate on testing what
>>>> gets released in XE.
>>>>
>>>> Both of these problems would be fixed if version numbers were
synchronized and everything was
>>>> branched for a release. Relevant questions which come to mind are
"do we need the capability to
>>>> release applications at separate times?" and "is there no way
to do that with synchronized version
>>>> numbers?"
>>>>
>>>> Am I missing any other reasons?
>>>> Should this not become a proposal?
>>>>
>>>> Caleb
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>
>> _______________________________________________
>> 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
>
_______________________________________________
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
8 Oct
8 Oct
12:12 p.m.
On Thu, Oct 7, 2010 at 10:51, Caleb James DeLisle
<calebdelisle(a)lavabit.com> wrote:
If the changes appear to be comparable then they should go from commit to release without
any
further testing, milestones or release candidates?
--
Thomas Mortagne
On 10/07/2010 03:24 AM, Marius Dumitru Florea wrote:
Which only mean that we don't need to branch that much, even the
application remain compatible with the stable branch or only
incompatible commits are done in the applications most of the time.
On 10/06/2010 03:28 PM, Caleb James DeLisle
wrote:
Let's take for example the administration application which is included in each
release of enterprise.
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.4/pom… <--
v1.37
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.4.1/p… <--
v1.38
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.4.2/p… <--
v1.39
in v2.3
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.3/pom… <--
v1.33
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.3.1/p… <--
v1.34
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.3.2/p… <--
v1.34 with a
comment above that 1.35 is incompatible.
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2/pom… <--
v1.26
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.1/p… <--
v1.27
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.2/p… <--
v1.28
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.3/p… <--
v1.29
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.4/p… <--
v1.30
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.5/p… <--
v1.32
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.6/p… <--
v1.33
So in the last three versions, every time except for 1, this was the practice.
I have been observing problems with the
versioning scheme which we are using.
Because applications are not branched along with
core, when a bugfix version of a stable branch is
released, new versions of applications are typically pulled in.
I'm not sure what you mean by "typically" here but I don't see the
need
to automatically release an application whenever a bug fix release of XE
is made and I don't think our release managers do this. If an
application has bug fixes too and these bug fixes are compatible with
the bug fix release of XE then yes, otherwise the application needs a
branch.
Branching to keep bug fixes to backport separate from regular development is a good idea,
but in
http://svn.xwiki.org/svnroot/xwiki/platform/xwiki-applications/branches/ I only see 4
branches have
ever been made. This means that `experimental' code
is being introduced into a `stable' branch in a bugfix version.
That's not true. When you commit to an application you have to check
which versions of XE depend on it and if your changes are not compatible with all of them then you have to make a branch.
I'm not convinced that synchronizing version numbers is a good idea. I'm
-0 for now.
Thanks,
Marius
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
This is not the path I would choose
but more importantly we can't honestly say that our code goes through a
milestone/release candidate
verification process if some of the code is allowed to bypass it.
This situation has caused me to make a mistake which I was able to correct during the
release
without major issue, I think the same issue is behind the release of 2 bogus versions
(2.4.1 and 2.4.2)
There is another issue, users who want to mix and match applications to build their own
wiki are
faced with a set of version numbers and no way to know what is compatible with what. A
user who I
spoke with last night had this very problem. We could publish a compatibility matrix but
if we were
to show all the versions a given application is compatible with, that would require
testing each
application version against each core version and I think we need to concentrate on
testing what
gets released in XE.
Both of these problems would be fixed if version numbers were synchronized and everything
was
branched for a release. Relevant questions which come to mind are "do we need the
capability to
release applications at separate times?" and "is there no way to do that with
synchronized version
numbers?"
Am I missing any other reasons?
Should this not become a proposal?
Caleb
_______________________________________________
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
8:16 p.m.
On 10/08/2010 12:12 PM, Thomas Mortagne wrote:
On Thu, Oct 7, 2010 at 10:51, Caleb James DeLisle
<calebdelisle(a)lavabit.com> wrote:
Applications rarely need branches because there are mostly two types of
changes that require branches:
- API changes, which are pretty rare
- Major Skin changes, which are also pretty rare.
2.4.1 was broken because of API changes.
2.4.2 was broken because of a skin change, and for which I locked down
the wrong version of the application.
Really, branching applications is not needed.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
On 10/07/2010 03:24 AM, Marius Dumitru Florea wrote:
Which only mean that we don't need to branch that much, even the
application remain compatible with the stable branch or only
incompatible commits are done in the applications most of the time. On 10/06/2010 03:28 PM, Caleb James DeLisle
wrote:
Let's take for example the administration application which is included in each
release of enterprise.
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.4/pom…
v1.37
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.4.1/p…
v1.38
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.4.2/p…
v1.39
in v2.3
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.3/pom…
v1.33
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.3.1/p…
v1.34
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.3.2/p…
v1.34 with a
comment above that 1.35 is incompatible.
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2/pom…
v1.26
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.1/p…
v1.27
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.2/p…
v1.28
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.3/p…
v1.29
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.4/p…
v1.30
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.5/p…
v1.32
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.6/p…
v1.33
So in the last three versions, every time except for 1, this was the practice.
I have been observing problems with the
versioning scheme which we are using.
Because applications are not branched along with
core, when a bugfix version of a stable branch is
released, new versions of applications are typically pulled in.
I'm not sure what you mean by "typically" here but I don't see the
need
to automatically release an application whenever a bug fix release of XE
is made and I don't think our release managers do this. If an
application has bug fixes too and these bug fixes are compatible with
the bug fix release of XE then yes, otherwise the application needs a
branch.
Branching to keep bug fixes to backport separate from regular development is a good idea,
but in
http://svn.xwiki.org/svnroot/xwiki/platform/xwiki-applications/branches/ I only see 4
branches have
ever been made. 
7 Oct
7 Oct
9:38 a.m.
New subject: [xwiki-devs] [discussion] Synchronizing version numbers of applications, plugins, and core.
Hi Caleb and all,
Here's my take:
1) I agree it's currently hard to know the compatibility of a given extension
2) Putting the XE version in the extension version is limiting IMO. Consider the following
typical use case:
-- we release XE version N and the Acme Extension version N
-- we make changes to Acme Extension
-- we release XE version N+1 and thus Acme Extension N+1
-- I'm a user with XE version N installed. I check to see if there's a new version
of the Acme Extension I use. I see Acme Extension N+1 but N+1 doesn't match my XE
version so I assume it's not going to work with XE version.
-- The problem is that this assumption is false. We would need to re-release every
extension N times whenever there are changes to it in order just to name them with the
past released XE versions...
3) We're developing an Extension Manager in charge of finding all available extensions
for you directly from your wiki and to install/upgrade them easily
4) The way the Extension Manager works is by looking at the dependency version in the
Maven POM for the extension. Thus the best practice is to use version ranges to show the
compatibility matrix of a given extension with XE core. Thus I propose several things:
-- that we start using version ranges in our extension POMs
-- that indeed we have a template on xwiki.org for users to contribute information on
whether a given extension works on a given XE release, in order to distribute the workload
of creating the compatibility matrix
-- when a user reports it work, we update the POM for the extension accordingly (same when
a user reports that it doesn't work)
In conclusion I don't think we need to change the current versioning scheme for
extensions and in any case we can't control all the extensions out there since the
idea is to promote the creation of XWiki extensions outside of the xwiki dev team and thus
we need a better mechanism than one based on the name.
Note: if you wanted to put the XE version in the extension name you'd need to allow
version range syntax in the name which is a pain since you'd need to re-release
everytime you learn that your extensions works or doesn't work with a given XE release
(barring the issue with special chars for some filesystems...).
Thanks
-Vincent
On Oct 6, 2010, at 2:28 PM, Caleb James DeLisle wrote:
I have been observing problems with the versioning
scheme which we are using.
Because applications are not branched along with core, when a bugfix version of a stable
branch is
released, new versions of applications are typically pulled in. This means that
`experimental' code
is being introduced into a `stable' branch in a bugfix version. This is not the path
I would choose
but more importantly we can't honestly say that our code goes through a
milestone/release candidate
verification process if some of the code is allowed to bypass it.
This situation has caused me to make a mistake which I was able to correct during the
release
without major issue, I think the same issue is behind the release of 2 bogus versions
(2.4.1 and 2.4.2)
There is another issue, users who want to mix and match applications to build their own
wiki are
faced with a set of version numbers and no way to know what is compatible with what. A
user who I
spoke with last night had this very problem. We could publish a compatibility matrix but
if we were
to show all the versions a given application is compatible with, that would require
testing each
application version against each core version and I think we need to concentrate on
testing what
gets released in XE.
Both of these problems would be fixed if version numbers were synchronized and everything
was
branched for a release. Relevant questions which come to mind are "do we need the
capability to
release applications at separate times?" and "is there no way to do that with
synchronized version
numbers?"
Am I missing any other reasons?
Should this not become a proposal?
Caleb
1:32 p.m.
New subject: [xwiki-devs] [discussion] Synchronizing version numbers of applications, plugins, and core.
On 10/07/2010 09:38 AM, Vincent Massol wrote:
4) The way the Extension Manager works is by looking
at the dependency version in the Maven POM for the extension. Thus the best practice is to
use version ranges to show the compatibility matrix of a given extension with XE core.
Thus I propose several things:
-- that we start using version ranges in our extension POMs
Currently there's a problem with version ranges and releases:
http://jira.codehaus.org/browse/MRELEASE-318
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
2:10 p.m.
New subject: [xwiki-devs] [discussion] Synchronizing version numbers of applications, plugins, and core.
On Oct 7, 2010, at 1:32 PM, Sergiu Dumitriu wrote:
On 10/07/2010 09:38 AM, Vincent Massol wrote:
This was supposedly fixed in Maven 2.1....
Thanks
-Vincent
4) The way the Extension Manager works is by
looking at the dependency version in the Maven POM for the extension. Thus the best
practice is to use version ranges to show the compatibility matrix of a given extension
with XE core. Thus I propose several things:
-- that we start using version ranges in our extension POMs
Currently there's a problem with version ranges and releases:
http://jira.codehaus.org/browse/MRELEASE-318
2:23 p.m.
On Thu, Oct 7, 2010 at 14:10, Vincent Massol <vincent(a)massol.net> wrote:
On Oct 7, 2010, at 1:32 PM, Sergiu Dumitriu wrote:
It's fixed in 2.1 but in release plugin 2.1 which is not yet released.
On 10/07/2010 09:38 AM, Vincent Massol wrote:
This was supposedly fixed in Maven 2.1.... 4) The way the Extension Manager works is by
looking at the dependency version in the Maven POM for the extension. Thus the best
practice is to use version ranges to show the compatibility matrix of a given extension
with XE core. Thus I propose several things:
-- that we start using version ranges in our extension POMs
Currently there's a problem with version ranges and releases:
http://jira.codehaus.org/browse/MRELEASE-318
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
2:27 p.m.
New subject: [xwiki-devs] [discussion] Synchronizing version numbers of applications, plugins, and core.
On 10/07/2010 02:10 PM, Vincent Massol wrote:
On Oct 7, 2010, at 1:32 PM, Sergiu Dumitriu wrote:
No, it is fixed in maven-release-plugin 2.1, which isn't out yet.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
On 10/07/2010 09:38 AM, Vincent Massol wrote:
This was supposedly fixed in Maven 2.1....
4) The way the Extension Manager works is by
looking at the dependency version in the Maven POM for the extension. Thus the best
practice is to use version ranges to show the compatibility matrix of a given extension
with XE core. Thus I propose several things:
-- that we start using version ranges in our extension POMs
Currently there's a problem with version ranges and releases:
http://jira.codehaus.org/browse/MRELEASE-318
2:13 p.m.
On Thu, Oct 7, 2010 at 13:32, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
On 10/07/2010 09:38 AM, Vincent Massol wrote:
2.1 should be released pretty soon I guess (I actually tough it was
already done).
4) The way the Extension Manager works is by
looking at the dependency version in the Maven POM for the extension. Thus the best
practice is to use version ranges to show the compatibility matrix of a given extension
with XE core. Thus I propose several things:
-- that we start using version ranges in our extension POMs
Currently there's a problem with version ranges and releases:
http://jira.codehaus.org/browse/MRELEASE-318
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
2:35 p.m.
New subject: [xwiki-devs] [discussion] Synchronizing version numbers of applications, plugins, and core.
On 10/07/2010 03:38 AM, Vincent Massol wrote:
Hi Caleb and all,
Here's my take:
1) I agree it's currently hard to know the compatibility of a given extension
2) Putting the XE version in the extension version is limiting IMO. Consider the
following typical use case:
-- we release XE version N and the Acme Extension version N
-- we make changes to Acme Extension
-- we release XE version N+1 and thus Acme Extension N+1
-- I'm a user with XE version N installed. I check to see if there's a new
version of the Acme Extension I use. I see Acme Extension N+1 but N+1 doesn't match my
XE version so I assume it's not going to work with XE version.
-- The problem is that this assumption is false. We would need to re-release every
extension N times whenever there are changes to it in order just to name them with the
past released XE versions...
It is sometimes false but IMO unless we do the testing to prove that it is false, we
should operate
under the assumption that it is true.
3) We're developing an Extension Manager in charge
of finding all available extensions for you directly from your wiki and to install/upgrade
them easily
4) The way the Extension Manager works is by looking at the dependency version in the
Maven POM for the extension. Thus the best practice is to use version ranges to show the
compatibility matrix of a given extension with XE core. Thus I propose several things:
-- that we start using version ranges in our extension POMs
And begin testing each version combination?
-- that indeed we have a template on xwiki.org for
users to contribute information on whether a given extension works on a given XE release,
in order to distribute the workload of creating the compatibility matrix
-- when a user reports it work, we update the POM for the extension accordingly (same
when a user reports that it doesn't work)
In conclusion I don't think we need to change the current versioning scheme for
extensions and in any case we
can't control all the extensions out there since
the idea is to promote the creation of XWiki extensions outside of the xwiki dev team
+1 and this makes me unsure about synchronizing versions since third parties will
use their own
versions and XWiki apps should work the same as third party apps, however for users to
know what is
compatible we will need the extension manager up and running, and for app developers to
know what
future core versions how long their will be compatible with, we will need some way to
signal how
long each given API function is guaranteed to exist.
Synchronization of versioning and branching/tagging is something which we can have now and
it
doesn't preclude adding a parameter for supported versions later on so I am going to
continue to
stand in my corner and make a stink :P
Definitely gave me something to think about though.
Caleb
and thus we need a better mechanism than one based on
the name.
Note: if you wanted to put the XE version in the extension name you'd need to allow
version range syntax in the name which is a pain since you'd need to re-release
everytime you learn that your extensions works or doesn't work with a given XE release
(barring the issue with special chars for some filesystems...).
Thanks
-Vincent
On Oct 6, 2010, at 2:28 PM, Caleb James DeLisle wrote:
I have been observing problems with the
versioning scheme which we are using.
Because applications are not branched along with core, when a bugfix version of a stable
branch is
released, new versions of applications are typically pulled in. This means that
`experimental' code
is being introduced into a `stable' branch in a bugfix version. This is not the path
I would choose
but more importantly we can't honestly say that our code goes through a
milestone/release candidate
verification process if some of the code is allowed to bypass it.
This situation has caused me to make a mistake which I was able to correct during the
release
without major issue, I think the same issue is behind the release of 2 bogus versions
(2.4.1 and 2.4.2)
There is another issue, users who want to mix and match applications to build their own
wiki are
faced with a set of version numbers and no way to know what is compatible with what. A
user who I
spoke with last night had this very problem. We could publish a compatibility matrix but
if we were
to show all the versions a given application is compatible with, that would require
testing each
application version against each core version and I think we need to concentrate on
testing what
gets released in XE.
Both of these problems would be fixed if version numbers were synchronized and everything
was
branched for a release. Relevant questions which come to mind are "do we need the
capability to
release applications at separate times?" and "is there no way to do that with
synchronized version
numbers?"
Am I missing any other reasons?
Should this not become a proposal?
Caleb
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
2:56 p.m.
New subject: [xwiki-devs] [discussion] Synchronizing version numbers of applications, plugins, and core.
Hi Vincent,
On 10/07/2010 09:38 AM, Vincent Massol wrote:
Hi Caleb and all,
Here's my take:
1) I agree it's currently hard to know the compatibility of a given extension
2) Putting the XE version in the extension version is limiting IMO. Consider the
following typical use case:
-- we release XE version N and the Acme Extension version N
-- we make changes to Acme Extension
-- we release XE version N+1 and thus Acme Extension N+1
-- I'm a user with XE version N installed. I check to see if there's a new
version of the Acme Extension I use. I see Acme Extension N+1 but N+1 doesn't match my
XE version so I assume it's not going to work with XE version.
-- The problem is that this assumption is false. We would need to re-release every
extension N times whenever there are changes to it in order just to name them with the
past released XE versions...
3) We're developing an Extension Manager in charge of finding all available
extensions for you directly from your wiki and to install/upgrade them easily
4) The way the Extension Manager works is by looking at the dependency version in the
Maven POM for the extension. Thus the best practice is to use version ranges to show the
compatibility matrix of a given extension with XE core. Thus I propose several things:
-- that we start using version ranges in our extension POMs
-- that indeed we have a template on xwiki.org for users to contribute information on
whether a given extension works on a given XE release, in order to distribute the workload
of creating the compatibility matrix
-- when a user reports it work, we update the POM for the extension accordingly (same
when a user reports that it doesn't work)
Indeed, the Extension Manager will be a great improvement, but it will
solve only a *half* of the problem - it will make it much easier for the
users, but not for the developers.
Currently, Java code is handled nicely in that respect - we *always*
have a branch for the next version, we have a development practices for
introducing of incompatible changes, bugs are fixed in both trunk and
last branch, new features go to trunk etc.
But why does this scheme not apply to the applications, which also
contain code and have exactly the same problems? It seems to me that
the only reason is the huge overhead created by the fact that *each*
application has its own version and release cycle. We ship a wild mix
of applications with different core versions, and everyone who wants to
make changes to them is supposed to take care of compatibility.
IMO the way applications are currently handled is a mess, which will
only be *hidden* from the users by the Extension Manager, and the only
way to make it easy for developers is to synchronize versions and apply
the strategy we have for core to all the applications at the same time.
Of course this strategy cannot be applied to 3rd party applications, but
we will only use them, so here the Extension Manager will take care of them.
Thanks,
Alex
In conclusion I don't think we need to change the
current versioning scheme for extensions and in any case we can't control all the
extensions out there since the idea is to promote the creation of XWiki extensions outside
of the xwiki dev team and thus we need a better mechanism than one based on the name.
Note: if you wanted to put the XE version in the extension name you'd need to allow
version range syntax in the name which is a pain since you'd need to re-release
everytime you learn that your extensions works or doesn't work with a given XE release
(barring the issue with special chars for some filesystems...).
Thanks
-Vincent
On Oct 6, 2010, at 2:28 PM, Caleb James DeLisle wrote:
I have been observing problems with the
versioning scheme which we are using.
Because applications are not branched along with core, when a bugfix version of a stable
branch is
released, new versions of applications are typically pulled in. This means that
`experimental' code
is being introduced into a `stable' branch in a bugfix version. This is not the path
I would choose
but more importantly we can't honestly say that our code goes through a
milestone/release candidate
verification process if some of the code is allowed to bypass it.
This situation has caused me to make a mistake which I was able to correct during the
release
without major issue, I think the same issue is behind the release of 2 bogus versions
(2.4.1 and 2.4.2)
There is another issue, users who want to mix and match applications to build their own
wiki are
faced with a set of version numbers and no way to know what is compatible with what. A
user who I
spoke with last night had this very problem. We could publish a compatibility matrix but
if we were
to show all the versions a given application is compatible with, that would require
testing each
application version against each core version and I think we need to concentrate on
testing what
gets released in XE.
Both of these problems would be fixed if version numbers were synchronized and everything
was
branched for a release. Relevant questions which come to mind are "do we need the
capability to
release applications at separate times?" and "is there no way to do that with
synchronized version
numbers?"
Am I missing any other reasons?
Should this not become a proposal?
Caleb
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
3:18 p.m.
New subject: [xwiki-devs] [discussion] Synchronizing version numbers of applications, plugins, and core.
On Oct 7, 2010, at 2:56 PM, Alex Busenius wrote:
Hi Vincent,
On 10/07/2010 09:38 AM, Vincent Massol wrote:
It does apply to everything, including applications.
Branches are only created on a need basis since there's no point in creating branches
if nothing will go in them and it would be useless to create branches for 100 extensions
when you don't know at all if any changes will be made in them.
Hi Caleb and all,
Here's my take:
1) I agree it's currently hard to know the compatibility of a given extension
2) Putting the XE version in the extension version is limiting IMO. Consider the
following typical use case:
-- we release XE version N and the Acme Extension version N
-- we make changes to Acme Extension
-- we release XE version N+1 and thus Acme Extension N+1
-- I'm a user with XE version N installed. I check to see if there's a new
version of the Acme Extension I use. I see Acme Extension N+1 but N+1 doesn't match my
XE version so I assume it's not going to work with XE version.
-- The problem is that this assumption is false. We would need to re-release every
extension N times whenever there are changes to it in order just to name them with the
past released XE versions...
3) We're developing an Extension Manager in charge of finding all available
extensions for you directly from your wiki and to install/upgrade them easily
4) The way the Extension Manager works is by looking at the dependency version in the
Maven POM for the extension. Thus the best practice is to use version ranges to show the
compatibility matrix of a given extension with XE core. Thus I propose several things:
-- that we start using version ranges in our extension POMs
-- that indeed we have a template on xwiki.org for users to contribute information on
whether a given extension works on a given XE release, in order to distribute the workload
of creating the compatibility matrix
-- when a user reports it work, we update the POM for the extension accordingly (same
when a user reports that it doesn't work)
Indeed, the Extension Manager will be a great improvement, but it will
solve only a *half* of the problem - it will make it much easier for the
users, but not for the developers.
Currently, Java code is handled nicely in that respect - we *always*
have a branch for the next version, we have a development practices for
introducing of incompatible changes, bugs are fixed in both trunk and
last branch, new features go to trunk etc.
But why does this scheme not apply to the applications, which also
contain code and have exactly the same problems? It seems to me that
the only reason is the huge overhead created by the fact that *each*
application has its own version and release cycle. We ship a wild mix
of applications with different core versions, and everyone who wants to
make changes to them is supposed to take care of compatibility.
Indeed, that's how it's working right now.
IMO the way applications are currently handled is a
mess, which will
only be *hidden* from the users by the Extension Manager, and the only
way to make it easy for developers is to synchronize versions and apply
the strategy we have for core to all the applications at the same time.
Can you please answer to my use case above to see how you'd handle it, because
that's the main issue I see. IMO your solution is very costly or it forces users to
always upgrade to the next XE version even when all they need is an application upgrade.
Thanks
-Vincent
Of course this strategy cannot be applied to 3rd party applications, but
we will only use them, so here the Extension Manager will take care of them.
Thanks,
Alex
> In conclusion I don't think we need to change the current versioning scheme for
extensions and in any case we can't control all the extensions out there since the
idea is to promote the creation of XWiki extensions outside of the xwiki dev team and thus
we need a better mechanism than one based on the name.
>
> Note: if you wanted to put the XE version in the extension name you'd need to
allow version range syntax in the name which is a pain since you'd need to re-release
everytime you learn that your extensions works or doesn't work with a given XE release
(barring the issue with special chars for some filesystems...).
>
> Thanks
> -Vincent
>
> On Oct 6, 2010, at 2:28 PM, Caleb James DeLisle wrote:
>
>> I have been observing problems with the versioning scheme which we are using.
>>
>> Because applications are not branched along with core, when a bugfix version of a
stable branch is
>> released, new versions of applications are typically pulled in. This means that
`experimental' code
>> is being introduced into a `stable' branch in a bugfix version. This is not
the path I would choose
>> but more importantly we can't honestly say that our code goes through a
milestone/release candidate
>> verification process if some of the code is allowed to bypass it.
>> This situation has caused me to make a mistake which I was able to correct during
the release
>> without major issue, I think the same issue is behind the release of 2 bogus
versions (2.4.1 and 2.4.2)
>>
>> There is another issue, users who want to mix and match applications to build
their own wiki are
>> faced with a set of version numbers and no way to know what is compatible with
what. A user who I
>> spoke with last night had this very problem. We could publish a compatibility
matrix but if we were
>> to show all the versions a given application is compatible with, that would
require testing each
>> application version against each core version and I think we need to concentrate
on testing what
>> gets released in XE.
>>
>> Both of these problems would be fixed if version numbers were synchronized and
everything was
>> branched for a release. Relevant questions which come to mind are "do we
need the capability to
>> release applications at separate times?" and "is there no way to do
that with synchronized version
>> numbers?"
>>
>> Am I missing any other reasons?
>> Should this not become a proposal?
>>
>> Caleb
8 Oct
8 Oct
4:58 a.m.
New subject: [xwiki-devs] [discussion] Synchronizing version numbers of applications, plugins, and core.
On 10/07/2010 03:18 PM, Vincent Massol wrote:
It does apply to everything, including applications.
Branches are only created on a need basis since there's no point in creating branches
if nothing will go in them and it would be useless to create branches for 100 extensions
when you don't know at all if any changes will be made in them.
The problem with on-demand branches is that nobody creates them and all
changes just go to trunk, which works most of the time, but not always.
Consider the following a use case (happened with 2.4.1):
- both XE version 2.4.0 (stable) and 2.5 are using App version X
- as usual, we have trunk for XE 2.5 and branch for XE 2.4.0
- App was not changed yet, so there is no branch
- the first change makes App dependent on 2.5 API, the change
(correctly) goes to trunk (future X+1), no branch is created since it
is still not needed
- a few weeks later, some other changes to App are committed to trunk
as usual, they do not introduce incompatibilities, so nobody thinks
about branching (again)
- in a few more weeks we release 2.4.1, all changed apps are released as
usual, among them App X+1, which breaks XE 2.4.1
The problem is that (as far as I understand the "on-demand" branching)
the _release manager_ needs to know which apps are compatible with the
stable branch and makes branches for them if needed.
Actually, _anyone_ who wants to fix a bug in App needs to check all
changes made to it so far, understand which ones are compatible with the
stable XE, branch App-X and merge all important compatible changes from
trunk + the actual bugfix to the new branch.
With synchronized versions, there would be no need to think about this,
new features would just go to trunk and bugfixes to both trunk and
stable branch (like everywhere else).
See above for the answer.
Users don't have to upgrade if they don't want to, they can always try a
newer version of the app and hope for the best (like they do it now).
Thanks,
Alex
On Oct 7, 2010, at 2:56 PM, Alex Busenius wrote:
> Hi Vincent,
>
> On 10/07/2010 09:38 AM, Vincent Massol wrote:
>> Hi Caleb and all,
>>
>> Here's my take:
>> 1) I agree it's currently hard to know the compatibility of a given
extension
>> 2) Putting the XE version in the extension version is limiting IMO. Consider the
following typical use case:
>> -- we release XE version N and the Acme Extension version N
>> -- we make changes to Acme Extension
>> -- we release XE version N+1 and thus Acme Extension N+1
>> -- I'm a user with XE version N installed. I check to see if there's a
new version of the Acme Extension I use. I see Acme Extension N+1 but N+1 doesn't
match my XE version so I assume it's not going to work with XE version.
>> -- The problem is that this assumption is false. We would need to re-release
every extension N times whenever there are changes to it in order just to name them with
the past released XE versions...
It depends on how we define compatibility, if we say that all x.y.*
versions are compatible among each other, then the choice will be easy.
In the future, Extension Manager will handle versions transparently for
the users (independent from versioning scheme), so it will become even
easier.
The overhead for releasing unchanged extensions is not that big IMO
because there are no exceptions and only one version to think about.
3) We're developing an Extension Manager in charge
of finding all available extensions for you directly from your wiki and to install/upgrade
them easily
4) The way the Extension Manager works is by looking at the dependency version in the
Maven POM for the extension. Thus the best practice is to use version ranges to show the
compatibility matrix of a given extension with XE core. Thus I propose several things:
-- that we start using version ranges in our extension POMs
-- that indeed we have a template on xwiki.org for users to contribute information on
whether a given extension works on a given XE release, in order to distribute the workload
of creating the compatibility matrix
-- when a user reports it work, we update the POM for the extension accordingly (same
when a user reports that it doesn't work)
Indeed, the Extension Manager will be a great improvement, but it will
solve only a *half* of the problem - it will make it much easier for the
users, but not for the developers.
Currently, Java code is handled nicely in that respect - we *always*
have a branch for the next version, we have a development practices for
introducing of incompatible changes, bugs are fixed in both trunk and
last branch, new features go to trunk etc.
But why does this scheme not apply to the applications, which also
contain code and have exactly the same problems? It seems to me that
the only reason is the huge overhead created by the fact that *each*
application has its own version and release cycle. We ship a wild mix
of applications with different core versions, and everyone who wants to
make changes to them is supposed to take care of compatibility.
Indeed, that's how it's working right now.
IMO the way applications are currently handled is
a mess, which will
only be *hidden* from the users by the Extension Manager, and the only
way to make it easy for developers is to synchronize versions and apply
the strategy we have for core to all the applications at the same time.
Can you please answer to my use case above to see how you'd handle it, because
that's the main issue I see. IMO your solution is very costly or it forces users to
always upgrade to the next XE version even when all they need is an application upgrade.
Thanks
-Vincent
Of course this strategy cannot be applied to 3rd party applications, but
we will only use them, so here the Extension Manager will take care of them.
Thanks,
Alex
> In conclusion I don't think we need to change the current versioning scheme for
extensions and in any case we can't control all the extensions out there since the
idea is to promote the creation of XWiki extensions outside of the xwiki dev team and thus
we need a better mechanism than one based on the name.
>
> Note: if you wanted to put the XE version in the extension name you'd need to
allow version range syntax in the name which is a pain since you'd need to re-release
everytime you learn that your extensions works or doesn't work with a given XE release
(barring the issue with special chars for some filesystems...).
>
> Thanks
> -Vincent
>
> On Oct 6, 2010, at 2:28 PM, Caleb James DeLisle wrote:
>
>> I have been observing problems with the versioning scheme which we are using.
>>
>> Because applications are not branched along with core, when a bugfix version of a
stable branch is
>> released, new versions of applications are typically pulled in. This means that
`experimental' code
>> is being introduced into a `stable' branch in a bugfix version. This is not
the path I would choose
>> but more importantly we can't honestly say that our code goes through a
milestone/release candidate
>> verification process if some of the code is allowed to bypass it.
>> This situation has caused me to make a mistake which I was able to correct during
the release
>> without major issue, I think the same issue is behind the release of 2 bogus
versions (2.4.1 and 2.4.2)
>>
>> There is another issue, users who want to mix and match applications to build
their own wiki are
>> faced with a set of version numbers and no way to know what is compatible with
what. A user who I
>> spoke with last night had this very problem. We could publish a compatibility
matrix but if we were
>> to show all the versions a given application is compatible with, that would
require testing each
>> application version against each core version and I think we need to concentrate
on testing what
>> gets released in XE.
>>
>> Both of these problems would be fixed if version numbers were synchronized and
everything was
>> branched for a release. Relevant questions which come to mind are "do we
need the capability to
>> release applications at separate times?" and "is there no way to do
that with synchronized version
>> numbers?"
>>
>> Am I missing any other reasons?
>> Should this not become a proposal?
>>
>> Caleb
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
9:10 a.m.
New subject: [xwiki-devs] [discussion] Synchronizing version numbers of applications, plugins, and core.
On 10/08/2010 05:58 AM, Alex Busenius wrote:
On 10/07/2010 03:18 PM, Vincent Massol wrote:
It does apply to everything, including applications.
Branches are only created on a need basis since there's no point in creating branches
if nothing will go in them and it would be useless to create branches for 100 extensions
when you don't know at all if any changes will be made in them.
The problem with on-demand branches is that nobody creates them and all
changes just go to trunk, which works most of the time, but not always.
Consider the following a use case (happened with 2.4.1):
- both XE version 2.4.0 (stable) and 2.5 are using App version X
- as usual, we have trunk for XE 2.5 and branch for XE 2.4.0
- App was not changed yet, so there is no branch
On Oct 7, 2010, at 2:56 PM, Alex Busenius wrote:
> Hi Vincent,
>
> On 10/07/2010 09:38 AM, Vincent Massol wrote:
>> Hi Caleb and all,
>>
>> Here's my take:
>> 1) I agree it's currently hard to know the compatibility of a given
extension
>> 2) Putting the XE version in the extension version is limiting IMO. Consider the
following typical use case:
>> -- we release XE version N and the Acme Extension version N
>> -- we make changes to Acme Extension
>> -- we release XE version N+1 and thus Acme Extension N+1
>> -- I'm a user with XE version N installed. I check to see if there's a
new version of the Acme Extension I use. I see Acme Extension N+1 but N+1 doesn't
match my XE version so I assume it's not going to work with XE version.
>> -- The problem is that this assumption is false. We would need to re-release
every extension N times whenever there are changes to it in order just to name them with
the past released XE versions...
It depends on how we define compatibility, if we say that all x.y.*
versions are compatible among each other, then the choice will be easy.
In the future, Extension Manager will handle versions transparently for
the users (independent from versioning scheme), so it will become even
easier.
The overhead for releasing unchanged extensions is not that big IMO
because there are no exceptions and only one version to think about.
3) We're developing an Extension Manager in charge
of finding all available extensions for you directly from your wiki and to install/upgrade
them easily
4) The way the Extension Manager works is by looking at the dependency version in the
Maven POM for the extension. Thus the best practice is to use version ranges to show the
compatibility matrix of a given extension with XE core. Thus I propose several things:
-- that we start using version ranges in our extension POMs
-- that indeed we have a template on xwiki.org for users to contribute information on
whether a given extension works on a given XE release, in order to distribute the workload
of creating the compatibility matrix
-- when a user reports it work, we update the POM for the extension accordingly (same
when a user reports that it doesn't work)
Indeed, the Extension Manager will be a great improvement, but it will
solve only a *half* of the problem - it will make it much easier for the
users, but not for the developers.
Currently, Java code is handled nicely in that respect - we *always*
have a branch for the next version, we have a development practices for
introducing of incompatible changes, bugs are fixed in both trunk and
last branch, new features go to trunk etc.
But why does this scheme not apply to the applications, - the first change makes App dependent on 2.5 API, the
change
(correctly) goes to trunk (future X+1), no branch is created since it
is still not needed
I don't agree with this. It's easy to determine which XE versions depend
on App version X (trunk) by looking at poms. So the committer is suppose
to know/check this. The only problem could be that the committer is not
aware that his change is not compatible with XE 2.4.1 but:
* if he follows the XWiki development (he's a committer after all and
thus he should follow devs mailing list) then he has an idea of what's
new and not backwards compatible in XE 2.5
* the committer knows if his change is a bug fix (needs to be included
in XE 2.4.1) or a new feature (only for XE 2.5)
* we agreed to continue supporting the last final release (2.4) while
working on the next release (2.5) so the committer is responsible to
ensure his bug fixes for 2.5-SNAPSHOT are properly integrated in 2.4.x
So IMO the committer should know that both XE 2.5 and XE 2.4.1 depend on
App version X and that his changes are not compatible with XE 2.4.1.
Given this, he must ask the release manager to create a branch for the
given application, update XE 2.5 dependency and then commit his changes
on application trunk (now X+1).
So changes are committed _correctly_ to trunk only if they don't break
anything. In your use case, changes to App version X break XE 2.4 branch
(next 2.4.1) instantly. In this case a branch for the App is needed
right away.
- a few weeks later, some other changes to App are
committed to trunk
as usual, they do not introduce incompatibilities, so nobody thinks
about branching (again)
- in a few more weeks we release 2.4.1, all changed
apps are released as
usual, among them App X+1, which breaks XE 2.4.1
I think you mean App X. XE 2.4-SNAPSHOT (branch, next 2.4.1) and XE
2.5-SNAPSHOT (trunk, future 2.5 final) depend on App version X-SNAPSHOT
so when XE 2.4.1 is released App version X final is released. App trunk
becomes X+1 and XE 2.4-SNAPSHOT (branch, next 2.4.2) and XE 2.5-SNAPSHOT
(trunk, future 2.5 final) now depend on it.
The problem is that (as far as I understand the "on-demand" branching)
the _release manager_ needs to know which apps are compatible with the
stable branch and makes branches for them if needed.
Actually, _anyone_ who wants to fix a bug in App needs to check all
changes made to it so far, understand which ones are compatible with the
stable XE, branch App-X and merge all important compatible changes from
trunk + the actual bugfix to the new branch.
I don't agree with this. The branch must be created when the first
incompatible change is made. Future changes are merged if needed as they
are introduced. You don't have to merge previous changes at all.
Marius
With synchronized versions, there would be no need to think about this,
new features would just go to trunk and bugfixes to both trunk and
stable branch (like everywhere else).
See above for the answer.
Users don't have to upgrade if they don't want to, they can always try a
newer version of the app and hope for the best (like they do it now).
Thanks,
Alex
which
also
contain code and have exactly the same problems? It seems to me that
the only reason is the huge overhead created by the fact that *each*
application has its own version and release cycle. We ship a wild mix
of applications with different core versions, and everyone who wants to
make changes to them is supposed to take care of compatibility.
Indeed, that's how it's working right now.
IMO the way applications are currently handled is
a mess, which will
only be *hidden* from the users by the Extension Manager, and the only
way to make it easy for developers is to synchronize versions and apply
the strategy we have for core to all the applications at the same time.
Can you please answer to my use case above to see how you'd handle it, because
that's the main issue I see. IMO your solution is very costly or it forces users to
always upgrade to the next XE version even when all they need is an application upgrade.
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Of course this strategy cannot be applied to 3rd party applications, but
we will only use them, so here the Extension Manager will take care of them.
Thanks,
Alex
> In conclusion I don't think we need to change the current versioning scheme for
extensions and in any case we can't control all the extensions out there since the
idea is to promote the creation of XWiki extensions outside of the xwiki dev team and thus
we need a better mechanism than one based on the name.
>
> Note: if you wanted to put the XE version in the extension name you'd need to
allow version range syntax in the name which is a pain since you'd need to re-release
everytime you learn that your extensions works or doesn't work with a given XE release
(barring the issue with special chars for some filesystems...).
>
> Thanks
> -Vincent
>
> On Oct 6, 2010, at 2:28 PM, Caleb James DeLisle wrote:
>
>> I have been observing problems with the versioning scheme which we are using.
>>
>> Because applications are not branched along with core, when a bugfix version of a
stable branch is
>> released, new versions of applications are typically pulled in. This means that
`experimental' code
>> is being introduced into a `stable' branch in a bugfix version. This is not
the path I would choose
>> but more importantly we can't honestly say that our code goes through a
milestone/release candidate
>> verification process if some of the code is allowed to bypass it.
>> This situation has caused me to make a mistake which I was able to correct during
the release
>> without major issue, I think the same issue is behind the release of 2 bogus
versions (2.4.1 and 2.4.2)
>>
>> There is another issue, users who want to mix and match applications to build
their own wiki are
>> faced with a set of version numbers and no way to know what is compatible with
what. A user who I
>> spoke with last night had this very problem. We could publish a compatibility
matrix but if we were
>> to show all the versions a given application is compatible with, that would
require testing each
>> application version against each core version and I think we need to concentrate
on testing what
>> gets released in XE.
>>
>> Both of these problems would be fixed if version numbers were synchronized and
everything was
>> branched for a release. Relevant questions which come to mind are "do we
need the capability to
>> release applications at separate times?" and "is there no way to do
that with synchronized version
>> numbers?"
>>
>> Am I missing any other reasons?
>> Should this not become a proposal?
>>
>> Caleb
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
9:40 a.m.
New subject: [xwiki-devs] [discussion] Synchronizing version numbers of applications, plugins, and core.
On 10/08/2010 03:10 AM, Marius Dumitru Florea wrote:
Do you agree that is it more difficult and error prone than simply branching the entire
repo as one?
If so, what is the justification for the increased difficulty (hence decreased
productivity.)
On 10/08/2010 05:58 AM, Alex Busenius wrote:
Is this a proposal? This is not the current practice.
On 10/07/2010 03:18 PM, Vincent Massol wrote:
The problem with on-demand branches is that nobody creates them and all
changes just go to trunk, which works most of the time, but not always.
Consider the following a use case (happened with 2.4.1):
- both XE version 2.4.0 (stable) and 2.5 are using App version X
- as usual, we have trunk for XE 2.5 and branch for XE 2.4.0
- App was not changed yet, so there is no branch
On Oct 7, 2010, at 2:56 PM, Alex Busenius wrote:
> Hi Vincent,
>
> On 10/07/2010 09:38 AM, Vincent Massol wrote:
>> Hi Caleb and all,
>>
>> Here's my take:
>> 1) I agree it's currently hard to know the compatibility of a given
extension
>> 2) Putting the XE version in the extension version is limiting IMO. Consider the
following typical use case:
>> -- we release XE version N and the Acme Extension version N
>> -- we make changes to Acme Extension
>> -- we release XE version N+1 and thus Acme Extension N+1
>> -- I'm a user with XE version N installed. I check to see if there's a
new version of the Acme Extension I use. I see Acme Extension N+1 but N+1 doesn't
match my XE version so I assume it's not going to work with XE version.
>> -- The problem is that this assumption is false. We would need to re-release
every extension N times whenever there are changes to it in order just to name them with
the past released XE versions...
It depends on how we define compatibility, if we say that all x.y.*
versions are compatible among each other, then the choice will be easy.
In the future, Extension Manager will handle versions transparently for
the users (independent from versioning scheme), so it will become even
easier.
The overhead for releasing unchanged extensions is not that big IMO
because there are no exceptions and only one version to think about.
> 3)
We're developing an Extension Manager in charge of finding all available extensions
for you directly from your wiki and to install/upgrade them easily
> 4) The way the Extension Manager works is by looking at the dependency version in the
Maven POM for the extension. Thus the best practice is to use version ranges to show the
compatibility matrix of a given extension with XE core. Thus I propose several things:
> -- that we start using version ranges in our extension POMs
> -- that indeed we have a template on xwiki.org for users to contribute information on
whether a given extension works on a given XE release, in order to distribute the workload
of creating the compatibility matrix
> -- when a user reports it work, we update the POM for the extension accordingly (same
when a user reports that it doesn't work)
>
Indeed, the Extension Manager will be a great improvement, but it will
solve only a *half* of the problem - it will make it much easier for the
users, but not for the developers.
Currently, Java code is handled nicely in that respect - we *always*
have a branch for the next version, we have a development practices for
introducing of incompatible changes, bugs are fixed in both trunk and
last branch, new features go to trunk etc.
But why does this scheme not apply to the applications,
It does apply to everything, including applications.
Branches are only created on a need basis since there's no point in creating branches
if nothing will go in them and it would be useless to create branches for 100 extensions
when you don't know at all if any changes will be made in them.
- the first change makes App dependent on 2.5
API, the change
(correctly) goes to trunk (future X+1), no branch is created since it
is still not needed
I don't agree with this. It's easy to determine which XE versions depend
on App version X (trunk) by looking at poms. So the committer is suppose
to know/check this. The only problem could be that the committer is not
aware that his change is not compatible with XE 2.4.1 but:
* if he follows the XWiki development (he's a committer after all and
thus he should follow devs mailing list) then he has an idea of what's
new and not backwards compatible in XE 2.5
* the committer knows if his change is a bug fix (needs to be included
in XE 2.4.1) or a new feature (only for XE 2.5)
* we agreed to continue supporting the last final release (2.4) while
working on the next release (2.5) so the committer is responsible to
ensure his bug fixes for 2.5-SNAPSHOT are properly integrated in 2.4.x
So IMO the committer should know that both XE 2.5 and XE 2.4.1 depend on
App version X and that his changes are not compatible with XE 2.4.1.
Given this, he must ask the release manager to create a branch for the
given application, update XE 2.5 dependency and then commit his changes
on application trunk (now X+1).
So changes are committed _correctly_ to trunk only if they don't break
anything. In your use case, changes to App version X break XE 2.4 branch
(next 2.4.1) instantly. In this case a branch for the App is needed
right away. - a few weeks later, some other changes to App
are committed to trunk
as usual, they do not introduce incompatibilities, so nobody thinks
about branching (again)
- in a few more weeks we release 2.4.1, all
changed apps are released as
usual, among them App X+1, which breaks XE 2.4.1
I think you mean App X. XE 2.4-SNAPSHOT (branch, next 2.4.1) and XE
2.5-SNAPSHOT (trunk, future 2.5 final) depend on App version X-SNAPSHOT
so when XE 2.4.1 is released App version X final is released. App trunk
becomes X+1 and XE 2.4-SNAPSHOT (branch, next 2.4.2) and XE 2.5-SNAPSHOT
(trunk, future 2.5 final) now depend on it.
The problem is that (as far as I understand the "on-demand" branching)
the _release manager_ needs to know which apps are compatible with the
stable branch and makes branches for them if needed.
Actually, _anyone_ who wants to fix a bug in App needs to check all
changes made to it so far, understand which ones are compatible with the
stable XE, branch App-X and merge all important compatible changes from
trunk + the actual bugfix to the new branch.
I don't agree with this. The branch must be created when the first
incompatible change is made. Future changes are merged if needed as they
are introduced. You don't have to merge previous changes at all.
Marius
With synchronized versions, there would be no need to think about this,
new features would just go to trunk and bugfixes to both trunk and
stable branch (like everywhere else).
See above for the answer.
Users don't have to upgrade if they don't want to, they can always try a
newer version of the app and hope for the best (like they do it now).
Thanks,
Alex
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
which
also
contain code and have exactly the same problems? It seems to me that
the only reason is the huge overhead created by the fact that *each*
application has its own version and release cycle. We ship a wild mix
of applications with different core versions, and everyone who wants to
make changes to them is supposed to take care of compatibility.
Indeed, that's how it's working right now.
IMO the way applications are currently handled is
a mess, which will
only be *hidden* from the users by the Extension Manager, and the only
way to make it easy for developers is to synchronize versions and apply
the strategy we have for core to all the applications at the same time.
Can you please answer to my use case above to see how you'd handle it, because
that's the main issue I see. IMO your solution is very costly or it forces users to
always upgrade to the next XE version even when all they need is an application upgrade.
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Of course this strategy cannot be applied to 3rd party applications, but
we will only use them, so here the Extension Manager will take care of them.
Thanks,
Alex
> In conclusion I don't think we need to change the current versioning scheme for
extensions and in any case we can't control all the extensions out there since the
idea is to promote the creation of XWiki extensions outside of the xwiki dev team and thus
we need a better mechanism than one based on the name.
>
> Note: if you wanted to put the XE version in the extension name you'd need to
allow version range syntax in the name which is a pain since you'd need to re-release
everytime you learn that your extensions works or doesn't work with a given XE release
(barring the issue with special chars for some filesystems...).
>
> Thanks
> -Vincent
>
> On Oct 6, 2010, at 2:28 PM, Caleb James DeLisle wrote:
>
>> I have been observing problems with the versioning scheme which we are using.
>>
>> Because applications are not branched along with core, when a bugfix version of a
stable branch is
>> released, new versions of applications are typically pulled in. This means that
`experimental' code
>> is being introduced into a `stable' branch in a bugfix version. This is not
the path I would choose
>> but more importantly we can't honestly say that our code goes through a
milestone/release candidate
>> verification process if some of the code is allowed to bypass it.
>> This situation has caused me to make a mistake which I was able to correct during
the release
>> without major issue, I think the same issue is behind the release of 2 bogus
versions (2.4.1 and 2.4.2)
>>
>> There is another issue, users who want to mix and match applications to build
their own wiki are
>> faced with a set of version numbers and no way to know what is compatible with
what. A user who I
>> spoke with last night had this very problem. We could publish a compatibility
matrix but if we were
>> to show all the versions a given application is compatible with, that would
require testing each
>> application version against each core version and I think we need to concentrate
on testing what
>> gets released in XE.
>>
>> Both of these problems would be fixed if version numbers were synchronized and
everything was
>> branched for a release. Relevant questions which come to mind are "do we
need the capability to
>> release applications at separate times?" and "is there no way to do
that with synchronized version
>> numbers?"
>>
>> Am I missing any other reasons?
>> Should this not become a proposal?
>>
>> Caleb
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
10:33 a.m.
New subject: [xwiki-devs] [discussion] Synchronizing version numbers of applications, plugins, and core.
On 10/08/2010 10:40 AM, Caleb James DeLisle wrote:
On 10/08/2010 03:10 AM, Marius Dumitru Florea wrote:
On 10/08/2010 05:58 AM, Alex Busenius wrote:
On 10/07/2010 03:18 PM, Vincent Massol wrote:
On Oct 7, 2010, at 2:56 PM, Alex Busenius wrote:
> Hi Vincent,
>
> On 10/07/2010 09:38 AM, Vincent Massol wrote:
>> Hi Caleb and all,
>>
>> Here's my take:
>> 1) I agree it's currently hard to know the compatibility of a given
extension
>> 2) Putting the XE version in the extension version is limiting IMO. Consider the
following typical use case:
>> -- we release XE version N and the Acme Extension version N
>> -- we make changes to Acme Extension
>> -- we release XE version N+1 and thus Acme Extension N+1
>> -- I'm a user with XE version N installed. I check to see if there's a
new version of the Acme Extension I use. I see Acme Extension N+1 but N+1 doesn't
match my XE version so I assume it's not going to work with XE version.
>> -- The problem is that this assumption is false. We would need to re-release
every extension N times whenever there are changes to it in order just to name them with
the past released XE versions...
It depends on how we define compatibility, if we say that all x.y.*
versions are compatible among each other, then the choice will be easy.
In the future, Extension Manager will handle versions transparently for
the users (independent from versioning scheme), so it will become even
easier.
The overhead for releasing unchanged extensions is not that big IMO
because there are no exceptions and only one version to think about.
>> 3) We're developing an Extension
Manager in charge of finding all available extensions for you directly from your wiki and
to install/upgrade them easily
>> 4) The way the Extension Manager works is by looking at the dependency version in
the Maven POM for the extension. Thus the best practice is to use version ranges to show
the compatibility matrix of a given extension with XE core. Thus I propose several
things:
>> -- that we start using version ranges in our extension POMs
>> -- that indeed we have a template on xwiki.org for users to contribute
information on whether a given extension works on a given XE release, in order to
distribute the workload of creating the compatibility matrix
>> -- when a user reports it work, we update the POM for the extension accordingly
(same when a user reports that it doesn't work)
>>
> Indeed, the Extension Manager will be a great improvement, but it will
> solve only a *half* of the problem - it will make it much easier for the
> users, but not for the developers.
>
> Currently, Java code is handled nicely in that respect - we *always*
> have a branch for the next version, we have a development practices for
> introducing of incompatible changes, bugs are fixed in both trunk and
> last branch, new features go to trunk etc.
>
> But why does this scheme not apply to the applications,
It does apply to everything, including applications.
Branches are only created on a need basis since there's no point in creating branches
if nothing will go in them and it would be useless to create branches for 100 extensions
when you don't know at all if any changes will be made in them.
The problem with on-demand branches is that nobody creates them and all
changes just go to trunk, which works most of the time, but not always.
Consider the following a use case (happened with 2.4.1):
- both XE version 2.4.0 (stable) and 2.5 are using App version X
- as usual, we have trunk for XE 2.5 and branch for XE 2.4.0
- App was not changed yet, so there is no branch - the first change makes App dependent on 2.5
API, the change
(correctly) goes to trunk (future X+1), no branch is created since it
is still not needed
I don't agree with this. It's easy to determine which XE versions depend
on App version X (trunk) by looking at poms. So the committer is suppose
to know/check this. The only problem could be that the committer is not
aware that his change is not compatible with XE 2.4.1 but:
* if he follows the XWiki development (he's a committer after all and
thus he should follow devs mailing list) then he has an idea of what's
new and not backwards compatible in XE 2.5
* the committer knows if his change is a bug fix (needs to be included
in XE 2.4.1) or a new feature (only for XE 2.5)
* we agreed to continue supporting the last final release (2.4) while
working on the next release (2.5) so the committer is responsible to
ensure his bug fixes for 2.5-SNAPSHOT are properly integrated in 2.4.x
So IMO the committer should know that both XE 2.5 and XE 2.4.1 depend on
App version X and that his changes are not compatible with XE 2.4.1.
Given this, he must ask the release manager to create a branch for the
given application, update XE 2.5 dependency and then commit his changes
on application trunk (now X+1).
So changes are committed _correctly_ to trunk only if they don't break
anything. In your use case, changes to App version X break XE 2.4 branch
(next 2.4.1) instantly. In this case a branch for the App is needed
right away. Is this a proposal? This is not the current practice.
I'm pretty sure this is the current practice. If not, then we're doing
the wrong thing IMO.
- a few weeks later, some other changes to App
are committed to trunk
as usual, they do not introduce incompatibilities, so nobody thinks
about branching (again)
- in a few more weeks we release 2.4.1, all
changed apps are released as
usual, among them App X+1, which breaks XE 2.4.1
I think you mean App X. XE 2.4-SNAPSHOT (branch, next 2.4.1) and XE
2.5-SNAPSHOT (trunk, future 2.5 final) depend on App version X-SNAPSHOT
so when XE 2.4.1 is released App version X final is released. App trunk
becomes X+1 and XE 2.4-SNAPSHOT (branch, next 2.4.2) and XE 2.5-SNAPSHOT
(trunk, future 2.5 final) now depend on it.
The problem is that (as far as I understand the "on-demand" branching)
the _release manager_ needs to know which apps are compatible with the
stable branch and makes branches for them if needed.
Actually, _anyone_ who wants to fix a bug in App needs to check all
changes made to it so far, understand which ones are compatible with the
stable XE, branch App-X and merge all important compatible changes from
trunk + the actual bugfix to the new branch.
I don't agree with this. The branch must be created when the first
incompatible change is made. Future changes are merged if needed as they
are introduced. You don't have to merge previous changes at all. Do you agree that is it more difficult and error prone
than simply branching the entire repo as one?
It's easier to branch the entire repo, I agree, but I don't think it's
error prone nor much more difficult to branch applications on demand.
If so, what is the justification for the increased
difficulty (hence decreased productivity.)
Modularity I guess. Let's imagine a critical bug is discovered in the
Administration application. We fix it and then what? Do we release a new
version of XE? Why force users to upgrade the entire XE when
applications are so easy to upgrade by XAR import (and it will be even
easier when the extension manager will be in place).
Marius
Marius
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
With synchronized versions, there would be no need to think about this,
new features would just go to trunk and bugfixes to both trunk and
stable branch (like everywhere else).
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
> which also
> contain code and have exactly the same problems? It seems to me that
> the only reason is the huge overhead created by the fact that *each*
> application has its own version and release cycle. We ship a wild mix
> of applications with different core versions, and everyone who wants to
> make changes to them is supposed to take care of compatibility.
Indeed, that's how it's working right now.
> IMO the way applications are currently handled is a mess, which will
> only be *hidden* from the users by the Extension Manager, and the only
> way to make it easy for developers is to synchronize versions and apply
> the strategy we have for core to all the applications at the same time.
Can you please answer to my use case above to see how you'd handle it, because
that's the main issue I see. IMO your solution is very costly or it forces users to
always upgrade to the next XE version even when all they need is an application upgrade.
See above for the answer.
Users don't have to upgrade if they don't want to, they can always try a
newer version of the app and hope for the best (like they do it now).
Thanks,
Alex
Thanks
-Vincent
>
> Of course this strategy cannot be applied to 3rd party applications, but
> we will only use them, so here the Extension Manager will take care of them.
>
>
> Thanks,
> Alex
>
>> In conclusion I don't think we need to change the current versioning scheme
for extensions and in any case we can't control all the extensions out there since the
idea is to promote the creation of XWiki extensions outside of the xwiki dev team and thus
we need a better mechanism than one based on the name.
>>
>> Note: if you wanted to put the XE version in the extension name you'd need to
allow version range syntax in the name which is a pain since you'd need to re-release
everytime you learn that your extensions works or doesn't work with a given XE release
(barring the issue with special chars for some filesystems...).
>>
>> Thanks
>> -Vincent
>>
>> On Oct 6, 2010, at 2:28 PM, Caleb James DeLisle wrote:
>>
>>> I have been observing problems with the versioning scheme which we are
using.
>>>
>>> Because applications are not branched along with core, when a bugfix version
of a stable branch is
>>> released, new versions of applications are typically pulled in. This means
that `experimental' code
>>> is being introduced into a `stable' branch in a bugfix version. This is
not the path I would choose
>>> but more importantly we can't honestly say that our code goes through a
milestone/release candidate
>>> verification process if some of the code is allowed to bypass it.
>>> This situation has caused me to make a mistake which I was able to correct
during the release
>>> without major issue, I think the same issue is behind the release of 2 bogus
versions (2.4.1 and 2.4.2)
>>>
>>> There is another issue, users who want to mix and match applications to build
their own wiki are
>>> faced with a set of version numbers and no way to know what is compatible
with what. A user who I
>>> spoke with last night had this very problem. We could publish a compatibility
matrix but if we were
>>> to show all the versions a given application is compatible with, that would
require testing each
>>> application version against each core version and I think we need to
concentrate on testing what
>>> gets released in XE.
>>>
>>> Both of these problems would be fixed if version numbers were synchronized
and everything was
>>> branched for a release. Relevant questions which come to mind are "do we
need the capability to
>>> release applications at separate times?" and "is there no way to do
that with synchronized version
>>> numbers?"
>>>
>>> Am I missing any other reasons?
>>> Should this not become a proposal?
>>>
>>> Caleb
_______________________________________________
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
10:45 a.m.
New subject: [xwiki-devs] [discussion] Synchronizing version numbers of applications, plugins, and core.
On 10/08/2010 04:33 AM, Marius Dumitru Florea wrote:
Yes, that's what happened in 2.4.2 and that's how it was dealt with.
On 10/08/2010 10:40 AM, Caleb James DeLisle wrote:
http://svn.xwiki.org/svnroot/xwiki/platform/xwiki-applications/branches/
Only 4 branches have ever been made, administration-1.10, panels-1.20, panels-1.35, and
wiki-manager-1.1.
If this is already an agreed upon practice then it must be outlined somewhere.
On 10/08/2010 03:10 AM, Marius Dumitru Florea wrote:
On 10/08/2010 05:58 AM, Alex Busenius wrote:
On 10/07/2010 03:18 PM, Vincent Massol wrote:
>
> On Oct 7, 2010, at 2:56 PM, Alex Busenius wrote:
>
>> Hi Vincent,
>>
>> On 10/07/2010 09:38 AM, Vincent Massol wrote:
>>> Hi Caleb and all,
>>>
>>> Here's my take:
>>> 1) I agree it's currently hard to know the compatibility of a given
extension
>>> 2) Putting the XE version in the extension version is limiting IMO. Consider
the following typical use case:
>>> -- we release XE version N and the Acme Extension version N
>>> -- we make changes to Acme Extension
>>> -- we release XE version N+1 and thus Acme Extension N+1
>>> -- I'm a user with XE version N installed. I check to see if there's
a new version of the Acme Extension I use. I see Acme Extension N+1 but N+1 doesn't
match my XE version so I assume it's not going to work with XE version.
>>> -- The problem is that this assumption is false. We would need to re-release
every extension N times whenever there are changes to it in order just to name them with
the past released XE versions...
It depends on how we define compatibility, if we say that all x.y.*
versions are compatible among each other, then the choice will be easy.
In the future, Extension Manager will handle versions transparently for
the users (independent from versioning scheme), so it will become even
easier.
The overhead for releasing unchanged extensions is not that big IMO
because there are no exceptions and only one version to think about.
>>> 3) We're developing an Extension Manager in charge of finding all
available extensions for you directly from your wiki and to install/upgrade them easily
>>> 4) The way the Extension Manager works is by looking at the dependency
version in the Maven POM for the extension. Thus the best practice is to use version
ranges to show the compatibility matrix of a given extension with XE core. Thus I propose
several things:
>>> -- that we start using version ranges in our extension POMs
>>> -- that indeed we have a template on xwiki.org for users to contribute
information on whether a given extension works on a given XE release, in order to
distribute the workload of creating the compatibility matrix
>>> -- when a user reports it work, we update the POM for the extension
accordingly (same when a user reports that it doesn't work)
>>>
>> Indeed, the Extension Manager will be a great improvement, but it will
>> solve only a *half* of the problem - it will make it much easier for the
>> users, but not for the developers.
>>
>> Currently, Java code is handled nicely in that respect - we *always*
>> have a branch for the next version, we have a development practices for
>> introducing of incompatible changes, bugs are fixed in both trunk and
>> last branch, new features go to trunk etc.
>>
>> But why does this scheme not apply to the applications,
>
> It does apply to everything, including applications.
>
> Branches are only created on a need basis since there's no point in creating
branches if nothing will go in them and it would be useless to create branches for 100
extensions when you don't know at all if any changes will be made in them.
>
The problem with on-demand branches is that nobody creates them and all
changes just go to trunk, which works most of the time, but not always.
Consider the following a use case (happened with 2.4.1):
- both XE version 2.4.0 (stable) and 2.5 are using App version X
- as usual, we have trunk for XE 2.5 and branch for XE 2.4.0
- App was not changed yet, so there is no branch
- the first change makes App dependent on 2.5
API, the change
(correctly) goes to trunk (future X+1), no branch is created since it
is still not needed
I don't agree with this. It's easy to determine which XE versions depend
on App version X (trunk) by looking at poms. So the committer is suppose
to know/check this. The only problem could be that the committer is not
aware that his change is not compatible with XE 2.4.1 but:
* if he follows the XWiki development (he's a committer after all and
thus he should follow devs mailing list) then he has an idea of what's
new and not backwards compatible in XE 2.5
* the committer knows if his change is a bug fix (needs to be included
in XE 2.4.1) or a new feature (only for XE 2.5)
* we agreed to continue supporting the last final release (2.4) while
working on the next release (2.5) so the committer is responsible to
ensure his bug fixes for 2.5-SNAPSHOT are properly integrated in 2.4.x
So IMO the committer should know that both XE 2.5 and XE 2.4.1 depend on
App version X and that his changes are not compatible with XE 2.4.1.
Given this, he must ask the release manager to create a branch for the
given application, update XE 2.5 dependency and then commit his changes
on application trunk (now X+1).
So changes are committed _correctly_ to trunk only if they don't break
anything. In your use case, changes to App version X break XE 2.4 branch
(next 2.4.1) instantly. In this case a branch for the App is needed
right away. Is this a proposal? This is not the current
practice.
I'm pretty sure this is the current practice. If not, then we're doing
the wrong thing IMO. - a few weeks later, some other changes to App
are committed to trunk
as usual, they do not introduce incompatibilities, so nobody thinks
about branching (again)
- in a few more weeks we release 2.4.1, all
changed apps are released as
usual, among them App X+1, which breaks XE 2.4.1
I think you mean App X. XE 2.4-SNAPSHOT (branch, next 2.4.1) and XE
2.5-SNAPSHOT (trunk, future 2.5 final) depend on App version X-SNAPSHOT
so when XE 2.4.1 is released App version X final is released. App trunk
becomes X+1 and XE 2.4-SNAPSHOT (branch, next 2.4.2) and XE 2.5-SNAPSHOT
(trunk, future 2.5 final) now depend on it.
The problem is that (as far as I understand the "on-demand" branching)
the _release manager_ needs to know which apps are compatible with the
stable branch and makes branches for them if needed.
Actually, _anyone_ who wants to fix a bug in App needs to check all
changes made to it so far, understand which ones are compatible with the
stable XE, branch App-X and merge all important compatible changes from
trunk + the actual bugfix to the new branch.
I don't agree with this. The branch must be created when the first
incompatible change is made. Future changes are merged if needed as they
are introduced. You don't have to merge previous changes at all. Do you agree that is it more difficult and error
prone than simply branching the entire repo as one?
It's easier to branch the entire repo, I agree, but I don't think it's
error prone nor much more difficult to branch applications on demand.
If so, what is the justification for the
increased difficulty (hence decreased productivity.)
Modularity I guess. Let's imagine a critical bug is discovered in the
Administration application. We fix it and then what? Do we release a new
version of XE? Why force users to upgrade the entire XE when
applications are so easy to upgrade by XAR import (and it will be even
easier when the extension manager will be in place).
Marius
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Marius
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
With synchronized versions, there would be no need to think about this,
new features would just go to trunk and bugfixes to both trunk and
stable branch (like everywhere else).
>> which also
>> contain code and have exactly the same problems? It seems to me that
>> the only reason is the huge overhead created by the fact that *each*
>> application has its own version and release cycle. We ship a wild mix
>> of applications with different core versions, and everyone who wants to
>> make changes to them is supposed to take care of compatibility.
>
> Indeed, that's how it's working right now.
>
>> IMO the way applications are currently handled is a mess, which will
>> only be *hidden* from the users by the Extension Manager, and the only
>> way to make it easy for developers is to synchronize versions and apply
>> the strategy we have for core to all the applications at the same time.
>
> Can you please answer to my use case above to see how you'd handle it, because
that's the main issue I see. IMO your solution is very costly or it forces users to
always upgrade to the next XE version even when all they need is an application upgrade.
See above for the answer.
Users don't have to upgrade if they don't want to, they can always try a
newer version of the app and hope for the best (like they do it now).
Thanks,
Alex
>
> Thanks
> -Vincent
>
>>
>> Of course this strategy cannot be applied to 3rd party applications, but
>> we will only use them, so here the Extension Manager will take care of them.
>>
>>
>> Thanks,
>> Alex
>>
>>> In conclusion I don't think we need to change the current versioning
scheme for extensions and in any case we can't control all the extensions out there
since the idea is to promote the creation of XWiki extensions outside of the xwiki dev
team and thus we need a better mechanism than one based on the name.
>>>
>>> Note: if you wanted to put the XE version in the extension name you'd
need to allow version range syntax in the name which is a pain since you'd need to
re-release everytime you learn that your extensions works or doesn't work with a given
XE release (barring the issue with special chars for some filesystems...).
>>>
>>> Thanks
>>> -Vincent
>>>
>>> On Oct 6, 2010, at 2:28 PM, Caleb James DeLisle wrote:
>>>
>>>> I have been observing problems with the versioning scheme which we are
using.
>>>>
>>>> Because applications are not branched along with core, when a bugfix
version of a stable branch is
>>>> released, new versions of applications are typically pulled in. This
means that `experimental' code
>>>> is being introduced into a `stable' branch in a bugfix version. This
is not the path I would choose
>>>> but more importantly we can't honestly say that our code goes through
a milestone/release candidate
>>>> verification process if some of the code is allowed to bypass it.
>>>> This situation has caused me to make a mistake which I was able to
correct during the release
>>>> without major issue, I think the same issue is behind the release of 2
bogus versions (2.4.1 and 2.4.2)
>>>>
>>>> There is another issue, users who want to mix and match applications to
build their own wiki are
>>>> faced with a set of version numbers and no way to know what is compatible
with what. A user who I
>>>> spoke with last night had this very problem. We could publish a
compatibility matrix but if we were
>>>> to show all the versions a given application is compatible with, that
would require testing each
>>>> application version against each core version and I think we need to
concentrate on testing what
>>>> gets released in XE.
>>>>
>>>> Both of these problems would be fixed if version numbers were
synchronized and everything was
>>>> branched for a release. Relevant questions which come to mind are
"do we need the capability to
>>>> release applications at separate times?" and "is there no way
to do that with synchronized version
>>>> numbers?"
>>>>
>>>> Am I missing any other reasons?
>>>> Should this not become a proposal?
>>>>
>>>> Caleb
>
> _______________________________________________
> 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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
11:02 a.m.
On Fri, Oct 8, 2010 at 10:45, Caleb James DeLisle
<calebdelisle(a)lavabit.com> wrote:
--
Thomas Mortagne
On 10/08/2010 04:33 AM, Marius Dumitru Florea wrote:
Yes, that's what happened in 2.4.2 and that's how it was dealt with.
No it's not. What happen is that the wrong version of panels has been
used in 2.4.2 so it was a XE packaging bug.
On 10/08/2010 10:40 AM, Caleb James DeLisle
wrote:
http://svn.xwiki.org/svnroot/xwiki/platform/xwiki-applications/branches/
Only 4 branches have ever been made, administration-1.10, panels-1.20, panels-1.35, and
wiki-manager-1.1.
If this is already an agreed upon practice then it must be outlined somewhere.
On 10/08/2010 03:10 AM, Marius Dumitru Florea wrote:
On 10/08/2010 05:58 AM, Alex Busenius wrote:
> On 10/07/2010 03:18 PM, Vincent Massol wrote:
>>
>> On Oct 7, 2010, at 2:56 PM, Alex Busenius wrote:
>>
>>> Hi Vincent,
>>>
>>> On 10/07/2010 09:38 AM, Vincent Massol wrote:
>>>> Hi Caleb and all,
>>>>
>>>> Here's my take:
>>>> 1) I agree it's currently hard to know the compatibility of a given
extension
>>>> 2) Putting the XE version in the extension version is limiting IMO.
Consider the following typical use case:
>>>> -- we release XE version N and the Acme Extension version N
>>>> -- we make changes to Acme Extension
>>>> -- we release XE version N+1 and thus Acme Extension N+1
>>>> -- I'm a user with XE version N installed. I check to see if
there's a new version of the Acme Extension I use. I see Acme Extension N+1 but N+1
doesn't match my XE version so I assume it's not going to work with XE version.
>>>> -- The problem is that this assumption is false. We would need to
re-release every extension N times whenever there are changes to it in order just to name
them with the past released XE versions...
>
> It depends on how we define compatibility, if we say that all x.y.*
> versions are compatible among each other, then the choice will be easy.
> In the future, Extension Manager will handle versions transparently for
> the users (independent from versioning scheme), so it will become even
> easier.
>
> The overhead for releasing unchanged extensions is not that big IMO
> because there are no exceptions and only one version to think about.
>
>>>> 3) We're developing an Extension Manager in charge of finding all
available extensions for you directly from your wiki and to install/upgrade them easily
>>>> 4) The way the Extension Manager works is by looking at the dependency
version in the Maven POM for the extension. Thus the best practice is to use version
ranges to show the compatibility matrix of a given extension with XE core. Thus I propose
several things:
>>>> -- that we start using version ranges in our extension POMs
>>>> -- that indeed we have a template on xwiki.org for users to contribute
information on whether a given extension works on a given XE release, in order to
distribute the workload of creating the compatibility matrix
>>>> -- when a user reports it work, we update the POM for the extension
accordingly (same when a user reports that it doesn't work)
>>>>
>>> Indeed, the Extension Manager will be a great improvement, but it will
>>> solve only a *half* of the problem - it will make it much easier for the
>>> users, but not for the developers.
>>>
>>> Currently, Java code is handled nicely in that respect - we *always*
>>> have a branch for the next version, we have a development practices for
>>> introducing of incompatible changes, bugs are fixed in both trunk and
>>> last branch, new features go to trunk etc.
>>>
>>> But why does this scheme not apply to the applications,
>>
>> It does apply to everything, including applications.
>>
>> Branches are only created on a need basis since there's no point in creating
branches if nothing will go in them and it would be useless to create branches for 100
extensions when you don't know at all if any changes will be made in them.
>>
> The problem with on-demand branches is that nobody creates them and all
> changes just go to trunk, which works most of the time, but not always.
>
> Consider the following a use case (happened with 2.4.1):
> - both XE version 2.4.0 (stable) and 2.5 are using App version X
> - as usual, we have trunk for XE 2.5 and branch for XE 2.4.0
> - App was not changed yet, so there is no branch
> - the first change makes App dependent on 2.5 API, the change
> (correctly) goes to trunk (future X+1), no branch is created since it
> is still not needed
I don't agree with this. It's easy to determine which XE versions depend
on App version X (trunk) by looking at poms. So the committer is suppose
to know/check this. The only problem could be that the committer is not
aware that his change is not compatible with XE 2.4.1 but:
* if he follows the XWiki development (he's a committer after all and
thus he should follow devs mailing list) then he has an idea of what's
new and not backwards compatible in XE 2.5
* the committer knows if his change is a bug fix (needs to be included
in XE 2.4.1) or a new feature (only for XE 2.5)
* we agreed to continue supporting the last final release (2.4) while
working on the next release (2.5) so the committer is responsible to
ensure his bug fixes for 2.5-SNAPSHOT are properly integrated in 2.4.x
So IMO the committer should know that both XE 2.5 and XE 2.4.1 depend on
App version X and that his changes are not compatible with XE 2.4.1.
Given this, he must ask the release manager to create a branch for the
given application, update XE 2.5 dependency and then commit his changes
on application trunk (now X+1).
So changes are committed _correctly_ to trunk only if they don't break
anything. In your use case, changes to App version X break XE 2.4 branch
(next 2.4.1) instantly. In this case a branch for the App is needed
right away.
Is this a proposal? This is not the current
practice.
I'm pretty sure this is the current practice. If not, then we're doing
the wrong thing IMO.
> - a few weeks later, some other changes to App are committed to trunk
> as usual, they do not introduce incompatibilities, so nobody thinks
> about branching (again)
> - in a few more weeks we release 2.4.1, all changed apps are released as
> usual, among them App X+1, which breaks XE 2.4.1
I think you mean App X. XE 2.4-SNAPSHOT (branch, next 2.4.1) and XE
2.5-SNAPSHOT (trunk, future 2.5 final) depend on App version X-SNAPSHOT
so when XE 2.4.1 is released App version X final is released. App trunk
becomes X+1 and XE 2.4-SNAPSHOT (branch, next 2.4.2) and XE 2.5-SNAPSHOT
(trunk, future 2.5 final) now depend on it.
>
> The problem is that (as far as I understand the "on-demand" branching)
> the _release manager_ needs to know which apps are compatible with the
> stable branch and makes branches for them if needed.
> Actually, _anyone_ who wants to fix a bug in App needs to check all
> changes made to it so far, understand which ones are compatible with the
> stable XE, branch App-X and merge all important compatible changes from
> trunk + the actual bugfix to the new branch.
I don't agree with this. The branch must be created when the first
incompatible change is made. Future changes are merged if needed as they
are introduced. You don't have to merge previous changes at all.
Do you agree that is it more difficult and error
prone than simply branching the entire repo as one?
It's easier to branch the entire repo, I agree, but I don't think it's
error prone nor much more difficult to branch applications on demand.
If so, what is the justification for the
increased difficulty (hence decreased productivity.)
Modularity I guess. Let's imagine a critical bug is discovered in the
Administration application. We fix it and then what? Do we release a new
version of XE? Why force users to upgrade the entire XE when
applications are so easy to upgrade by XAR import (and it will be even
easier when the extension manager will be in place).
Marius
_______________________________________________
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
Marius
>
> With synchronized versions, there would be no need to think about this,
> new features would just go to trunk and bugfixes to both trunk and
> stable branch (like everywhere else).
>
>
>>> which also
>>> contain code and have exactly the same problems? It seems to me that
>>> the only reason is the huge overhead created by the fact that *each*
>>> application has its own version and release cycle. We ship a wild mix
>>> of applications with different core versions, and everyone who wants to
>>> make changes to them is supposed to take care of compatibility.
>>
>> Indeed, that's how it's working right now.
>>
>>> IMO the way applications are currently handled is a mess, which will
>>> only be *hidden* from the users by the Extension Manager, and the only
>>> way to make it easy for developers is to synchronize versions and apply
>>> the strategy we have for core to all the applications at the same time.
>>
>> Can you please answer to my use case above to see how you'd handle it,
because that's the main issue I see. IMO your solution is very costly or it forces
users to always upgrade to the next XE version even when all they need is an application
upgrade.
>
> See above for the answer.
>
> Users don't have to upgrade if they don't want to, they can always try a
> newer version of the app and hope for the best (like they do it now).
>
>
> Thanks,
> Alex
>
>>
>> Thanks
>> -Vincent
>>
>>>
>>> Of course this strategy cannot be applied to 3rd party applications, but
>>> we will only use them, so here the Extension Manager will take care of them.
>>>
>>>
>>> Thanks,
>>> Alex
>>>
>>>> In conclusion I don't think we need to change the current versioning
scheme for extensions and in any case we can't control all the extensions out there
since the idea is to promote the creation of XWiki extensions outside of the xwiki dev
team and thus we need a better mechanism than one based on the name.
>>>>
>>>> Note: if you wanted to put the XE version in the extension name you'd
need to allow version range syntax in the name which is a pain since you'd need to
re-release everytime you learn that your extensions works or doesn't work with a given
XE release (barring the issue with special chars for some filesystems...).
>>>>
>>>> Thanks
>>>> -Vincent
>>>>
>>>> On Oct 6, 2010, at 2:28 PM, Caleb James DeLisle wrote:
>>>>
>>>>> I have been observing problems with the versioning scheme which we
are using.
>>>>>
>>>>> Because applications are not branched along with core, when a bugfix
version of a stable branch is
>>>>> released, new versions of applications are typically pulled in. This
means that `experimental' code
>>>>> is being introduced into a `stable' branch in a bugfix version.
This is not the path I would choose
>>>>> but more importantly we can't honestly say that our code goes
through a milestone/release candidate
>>>>> verification process if some of the code is allowed to bypass it.
>>>>> This situation has caused me to make a mistake which I was able to
correct during the release
>>>>> without major issue, I think the same issue is behind the release of
2 bogus versions (2.4.1 and 2.4.2)
>>>>>
>>>>> There is another issue, users who want to mix and match applications
to build their own wiki are
>>>>> faced with a set of version numbers and no way to know what is
compatible with what. A user who I
>>>>> spoke with last night had this very problem. We could publish a
compatibility matrix but if we were
>>>>> to show all the versions a given application is compatible with, that
would require testing each
>>>>> application version against each core version and I think we need to
concentrate on testing what
>>>>> gets released in XE.
>>>>>
>>>>> Both of these problems would be fixed if version numbers were
synchronized and everything was
>>>>> branched for a release. Relevant questions which come to mind are
"do we need the capability to
>>>>> release applications at separate times?" and "is there no
way to do that with synchronized version
>>>>> numbers?"
>>>>>
>>>>> Am I missing any other reasons?
>>>>> Should this not become a proposal?
>>>>>
>>>>> Caleb
>>
>> _______________________________________________
>> 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
_______________________________________________
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
10:39 a.m.
I agree with Marius here and for most part that exactly how we always worked.
On Fri, Oct 8, 2010 at 09:10, Marius Dumitru Florea
<mariusdumitru.florea(a)xwiki.com> wrote:
On 10/08/2010 05:58 AM, Alex Busenius wrote:
You forget some current rules that makes your use case not an issue at all:
* the committer is introducing something that is not compatible with
2.4 branch, he indicate it in XE 2.4-SNAPSHOT. Look at
http://svn.xwiki.org/svnroot/xwiki/enterprise/branches/xwiki-enterprise-2.4…
* there is supposed to be a jira issue describing this important
change and release manager always look at the application issue one by
one when nothing is explicitely indicated in the XE pom file to make
sure it's OK to include this application
In the case of 2.4.1 you broke all application for 2.4 branch without
any jira issue and without indicate in XE which appllications were not
compatible anymore.
Then when something important for both 2.4 and 2.5 branch need to be
comitted the committer look at XE pom, see that the application is not
compatible anymore and then create a branch based on the last
compatible tag of the application.
On 10/07/2010 03:18 PM, Vincent Massol wrote:
The problem with on-demand branches is that nobody creates them and all
changes just go to trunk, which works most of the time, but not always.
Consider the following a use case (happened with 2.4.1):
- both XE version 2.4.0 (stable) and 2.5 are using App version X
- as usual, we have trunk for XE 2.5 and branch for XE 2.4.0
- App was not changed yet, so there is no branch
> - the first change makes App dependent on 2.5 API, the change
> (correctly) goes to trunk (future X+1), no branch is created since it
> is still not needed
On Oct 7, 2010, at 2:56 PM, Alex Busenius wrote:
> Hi Vincent,
>
> On 10/07/2010 09:38 AM, Vincent Massol wrote:
>> Hi Caleb and all,
>>
>> Here's my take:
>> 1) I agree it's currently hard to know the compatibility of a given
extension
>> 2) Putting the XE version in the extension version is limiting IMO. Consider the
following typical use case:
>> -- we release XE version N and the Acme Extension version N
>> -- we make changes to Acme Extension
>> -- we release XE version N+1 and thus Acme Extension N+1
>> -- I'm a user with XE version N installed. I check to see if there's a
new version of the Acme Extension I use. I see Acme Extension N+1 but N+1 doesn't
match my XE version so I assume it's not going to work with XE version.
>> -- The problem is that this assumption is false. We would need to re-release
every extension N times whenever there are changes to it in order just to name them with
the past released XE versions...
It depends on how we define compatibility, if we say that all x.y.*
versions are compatible among each other, then the choice will be easy.
In the future, Extension Manager will handle versions transparently for
the users (independent from versioning scheme), so it will become even
easier.
The overhead for releasing unchanged extensions is not that big IMO
because there are no exceptions and only one version to think about.
> 3)
We're developing an Extension Manager in charge of finding all available extensions
for you directly from your wiki and to install/upgrade them easily
> 4) The way the Extension Manager works is by looking at the dependency version in the
Maven POM for the extension. Thus the best practice is to use version ranges to show the
compatibility matrix of a given extension with XE core. Thus I propose several things:
> -- that we start using version ranges in our extension POMs
> -- that indeed we have a template on xwiki.org for users to contribute information on
whether a given extension works on a given XE release, in order to distribute the workload
of creating the compatibility matrix
> -- when a user reports it work, we update the POM for the extension accordingly (same
when a user reports that it doesn't work)
>
Indeed, the Extension Manager will be a great improvement, but it will
solve only a *half* of the problem - it will make it much easier for the
users, but not for the developers.
Currently, Java code is handled nicely in that respect - we *always*
have a branch for the next version, we have a development practices for
introducing of incompatible changes, bugs are fixed in both trunk and
last branch, new features go to trunk etc.
But why does this scheme not apply to the applications,
It does apply to everything, including applications.
Branches are only created on a need basis since there's no point in creating branches
if nothing will go in them and it would be useless to create branches for 100 extensions
when you don't know at all if any changes will be made in them.
I don't agree with this. It's easy to determine which XE versions depend
on App version X (trunk) by looking at poms. So the committer is suppose
to know/check this. The only problem could be that the committer is not
aware that his change is not compatible with XE 2.4.1 but:
* if he follows the XWiki development (he's a committer after all and
thus he should follow devs mailing list) then he has an idea of what's
new and not backwards compatible in XE 2.5
* the committer knows if his change is a bug fix (needs to be included
in XE 2.4.1) or a new feature (only for XE 2.5)
* we agreed to continue supporting the last final release (2.4) while
working on the next release (2.5) so the committer is responsible to
ensure his bug fixes for 2.5-SNAPSHOT are properly integrated in 2.4.x
So IMO the committer should know that both XE 2.5 and XE 2.4.1 depend on
App version X and that his changes are not compatible with XE 2.4.1.
Given this, he must ask the release manager to create a branch for the
given application, update XE 2.5 dependency and then commit his changes
on application trunk (now X+1).
So changes are committed _correctly_ to trunk only if they don't break
anything. In your use case, changes to App version X break XE 2.4 branch
(next 2.4.1) instantly. In this case a branch for the App is needed
right away.
--
Thomas Mortagne
- a few weeks later, some other changes to App
are committed to trunk
as usual, they do not introduce incompatibilities, so nobody thinks
about branching (again)
- in a few more weeks we release 2.4.1, all
changed apps are released as
usual, among them App X+1, which breaks XE 2.4.1
I think you mean App X. XE 2.4-SNAPSHOT (branch, next 2.4.1) and XE
2.5-SNAPSHOT (trunk, future 2.5 final) depend on App version X-SNAPSHOT
so when XE 2.4.1 is released App version X final is released. App trunk
becomes X+1 and XE 2.4-SNAPSHOT (branch, next 2.4.2) and XE 2.5-SNAPSHOT
(trunk, future 2.5 final) now depend on it.
The problem is that (as far as I understand the "on-demand" branching)
the _release manager_ needs to know which apps are compatible with the
stable branch and makes branches for them if needed.
Actually, _anyone_ who wants to fix a bug in App needs to check all
changes made to it so far, understand which ones are compatible with the
stable XE, branch App-X and merge all important compatible changes from
trunk + the actual bugfix to the new branch.
I don't agree with this. The branch must be created when the first
incompatible change is made. Future changes are merged if needed as they
are introduced. You don't have to merge previous changes at all.
Marius
With synchronized versions, there would be no need to think about this,
new features would just go to trunk and bugfixes to both trunk and
stable branch (like everywhere else).
See above for the answer.
Users don't have to upgrade if they don't want to, they can always try a
newer version of the app and hope for the best (like they do it now).
Thanks,
Alex
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
which
also
contain code and have exactly the same problems? It seems to me that
the only reason is the huge overhead created by the fact that *each*
application has its own version and release cycle. We ship a wild mix
of applications with different core versions, and everyone who wants to
make changes to them is supposed to take care of compatibility.
Indeed, that's how it's working right now.
IMO the way applications are currently handled is
a mess, which will
only be *hidden* from the users by the Extension Manager, and the only
way to make it easy for developers is to synchronize versions and apply
the strategy we have for core to all the applications at the same time.
Can you please answer to my use case above to see how you'd handle it, because
that's the main issue I see. IMO your solution is very costly or it forces users to
always upgrade to the next XE version even when all they need is an application upgrade.
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Of course this strategy cannot be applied to 3rd party applications, but
we will only use them, so here the Extension Manager will take care of them.
Thanks,
Alex
> In conclusion I don't think we need to change the current versioning scheme for
extensions and in any case we can't control all the extensions out there since the
idea is to promote the creation of XWiki extensions outside of the xwiki dev team and thus
we need a better mechanism than one based on the name.
>
> Note: if you wanted to put the XE version in the extension name you'd need to
allow version range syntax in the name which is a pain since you'd need to re-release
everytime you learn that your extensions works or doesn't work with a given XE release
(barring the issue with special chars for some filesystems...).
>
> Thanks
> -Vincent
>
> On Oct 6, 2010, at 2:28 PM, Caleb James DeLisle wrote:
>
>> I have been observing problems with the versioning scheme which we are using.
>>
>> Because applications are not branched along with core, when a bugfix version of a
stable branch is
>> released, new versions of applications are typically pulled in. This means that
`experimental' code
>> is being introduced into a `stable' branch in a bugfix version. This is not
the path I would choose
>> but more importantly we can't honestly say that our code goes through a
milestone/release candidate
>> verification process if some of the code is allowed to bypass it.
>> This situation has caused me to make a mistake which I was able to correct during
the release
>> without major issue, I think the same issue is behind the release of 2 bogus
versions (2.4.1 and 2.4.2)
>>
>> There is another issue, users who want to mix and match applications to build
their own wiki are
>> faced with a set of version numbers and no way to know what is compatible with
what. A user who I
>> spoke with last night had this very problem. We could publish a compatibility
matrix but if we were
>> to show all the versions a given application is compatible with, that would
require testing each
>> application version against each core version and I think we need to concentrate
on testing what
>> gets released in XE.
>>
>> Both of these problems would be fixed if version numbers were synchronized and
everything was
>> branched for a release. Relevant questions which come to mind are "do we
need the capability to
>> release applications at separate times?" and "is there no way to do
that with synchronized version
>> numbers?"
>>
>> Am I missing any other reasons?
>> Should this not become a proposal?
>>
>> Caleb
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5092
days inactive
5094
days old
37 comments
8 participants
participants (8)
-
[Ricardo Rodriguez] eBioTIC. -
Alex Busenius -
Caleb James DeLisle -
Fabio Mancinelli -
Marius Dumitru Florea -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol