7 Oct
2010
7 Oct
'10
2:35 p.m.
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