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.