On 10/06/2010 04:49 PM, [Ricardo Rodriguez] eBioTIC. wrote:
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.
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.
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