On 21 Jun 2016, at 23:22, Eduard Moraru <[email protected]> wrote:
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.
EM is core for sure. That’s the way XWiki is built.
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.
Sure, I agree. I was clumsy in the previous thread, what I meant was that the ability to add extensions could be even be considered as not being a feature of a basic wiki (but would still be used underneath by us since we need it). But anyway, I completely agree about what we said in the past and what you said again here, that is that if we push it to the end, EM may even be what remains when all else has been externalized as extensions. Right now though, a good first step towards that direction (and that’s already challenging) is to give the direction that the Base Flavor be corresponding to a “basic wiki”. Once we reach that level we can then discuss about going further (or not). Thanks -Vincent
Thanks, Eduard
On Tue, Jun 21, 2016 at 7:54 PM, Alexandru Cotiuga < [email protected]> wrote:
+1 (not binding)
On Tue, Jun 21, 2016 at 7:19 PM, Ecaterina Moraru (Valica) < [email protected]> 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 <[email protected]> wrote:
On Tue, Jun 21, 2016 at 6:00 PM, Vincent Massol <[email protected]> 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