Re: [xwiki-devs] [discussion] Synchronizing version numbers of applications, plugins, and core.

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