Hi,
+1. Even if it would imply a bit more work and management, I think it was
unavoidable due to XWiki`s platform nature.
My only note was about the mention on the previous thread that EM
would/could not be considered part of the base flavor, in that I`m not sure
I agree with that and, again, due to the platform nature of XWiki, EM
should be considered core. We were even discussing in the past that the
minimal distribution could be EM *alone*... so I can`t agree now with
removing it. I know it was just an idea, just want to clarify it.
Thanks,
Eduard
On Tue, Jun 21, 2016 at 7:54 PM, Alexandru Cotiuga <
alexandru.cotiuga(a)xwiki.com> wrote:
+1 (not binding)
On Tue, Jun 21, 2016 at 7:19 PM, Ecaterina Moraru (Valica) <
valicac(a)gmail.com> wrote:
+1
I like the fact that we don't move things around and that we support old
versions of XWiki.
We still need to clearly define what Base Flavor / Default Flavor include
and how contrib users will create new Flavors on top of them.
We still need to define the versioning scheme for the extensions that
will
go in the Default Flavor or in other possible
future 'supported' contrib
Flavors. (especially since you said they could have multiple releases)
(maybe something like 8.2.1-x, although might be strange that you could
install an 8.2.1-1 version of Tour in a 6.4 XWiki. Maybe we could use the
year like 2016-1-1 or I don't know we need to think about it). And we
need
to see where we document what each Flavor
contains and the procedure to
add/remove extensions in the Flavors.
Thanks,
Caty
On Tue, Jun 21, 2016 at 7:09 PM, Denis Gervalle <dgl(a)softec.lu> wrote:
On Tue, Jun 21, 2016 at 6: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).
> * 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.
> >
>
> IMO, the overhead will depends on the needs, but what will be a net
> benefice is not to artificially raise extensions requirements when
there
is
> no change, or when the change does not implies the need for a recent
API.
+1, of course :)
Here’s my +1
Please cast your vote.
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs