8 Oct
2010
8 Oct
'10
4:58 a.m.
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