On 22 Jun 2016, at 10:02, Marius Dumitru Florea
<mariusdumitru.florea(a)xwiki.com> wrote:
+1
On Tue, Jun 21, 2016 at 7:00 PM, Vincent Massol <vincent(a)massol.net> wrote:
Hi devs,
I’m transforming the brainstorming that was started in the thread
http://markmail.org/message/exlndbq3tw2thmmu into a VOTE mail since this
is a very important decision.
So I’m asking you to vote for defining a new direction for the XWiki Core
Dev Team (i.e. for the XWiki GitHub Organization). The need was triggered
by the Tour and CKEditor extensions which are currently in xwiki-contrib
and that we want our users to have by default. For more details see this
thread:
http://markmail.org/message/exlndbq3tw2thmmu
So here’s the strategy:
* Make XWiki Github org == minimal runtime, where minimal means “basic
wiki” (page edition, history, linking, wiki markup, etc). The notion of
“basic wiki” would need to be better defined but this can be done later on.
* Provide a "Base Flavor" which corresponds to this “basic wiki”, as part
of xwiki-platform (this would be xwiki-platform-distribution).
* Provide another flavor, the "Default Flavor” which would add some
hand-picked third-party extensions (i.e. from contrib) such as the Tour app
and CKEditor (to start with, we could also add the markdown syntax for
example which is one of the most asked syntaxes). Note that this Default
Flavor would actually be a “replacement" of xwiki-enterprise.
* The Default Flavor would have at least the same
release cycle as the
base flavor but it could have more releases (if some of the bundled
third-party extensions has some important bug fixes or new features that we
want to offer quickly without waiting for the next base flavor release).
I don't think we need to release the Default Flavor more often than the
Base Flavor because with this new strategy the users can upgrade individual
extensions (those that are not in the Base Flavor) without upgrading the
WAR.
As I said, if we find some important bug (for example) and this bug is only in one of the
3rd party extensions, it would be a pity not to release just the Default Flavor IMO and
wait for 2 months more. Even if users can upgrade their extensions, it’s better that users
new to XWiki download/install the best possible version right away instead of having to
upgrade.
We’ll see when the need arises but I don’t think we should stop ourselves from this
possibility. Technically this means putting the Default Flavor in a separate github repo
(same as xwiki-enterprise being in a separate repo). We need to discuss how we do it:
- consider it’s XE for now and just add the 2 deps of Tour and CK to XE
- introduce a new repo for the default flavor and do the build for it and deprecate XE in
favor of it. For now we probably need to hardcode the flavor id in the platform WAR till
we’re ready to have the flavor selection screen at startup (and for HSQLDB/Jetty packaging
we need a hard-coded flavor anyway).
Thanks
-Vincent
Currently the users cannot upgrade the Blog because
the new version of
the Blog depends on a new version of the XWiki WAR. With this new strategy
the users will be able to upgrade the Blog (considering that the Blog is
not part of the Base Flavor).
On the same topic, we have the Extension Updater administration section
where users can check for extension updates. The problem is that the
extensions included in a flavor are considered dependencies of the flavor
and thus are installed as dependencies which means the Extension Updater
cannot separate them from other technical dependencies and thus won't check
for their updates. Ideally a flavor should be a pack of extensions that are
installed explicitly (not as dependencies). This way the Extension Updater
can propose updates and at the same time the users can uninstall extensions
from a flavor without removing the flavor.
Thanks,
Marius
> * The consequence is that the XWiki Dev Team would need to be a bit more
> careful to monitor the quality of bundled third-party extensions in contrib
> (check commits, do some smoke testing, etc). Note that the goal of the
> Default flavor would not be to offer verticals (for this there should be
> some contrib flavors) and thus it wouldn’t bundle a lot of third-party
> extensions. Basically we’ll need to validate the version of those
> third-party extensions that include in the flavor.
>
> My POV is that globally this would offer more flexibility for our users
> (they’ll be able to install extensions such as CK and Tour in older XWiki
> versions and they’ll get more frequent releases) at the cost of some
> overhead to develop extensions that work in several versions. The dev team
> is pretty small and thus it means developing a bit less fast but it’s
> probably as important, if not more important, to make the code we develop
> available in older xwiki versions, as XWiki gains traction.
>
> Here’s my +1
>
> Please cast your vote.
>
> Thanks
> -Vincent