Re: [xwiki-devs] [Proposal] Update database support strategy
> On 13 Nov 2018, at 11:58, Vincent Massol wrote:
>
> There are 2 questions here:
> * Should we add support for MariaDB? And if so which versions. Just found
> that there’s an official docker image for it so it should be relatively easy
> to support MariaDB in our docker-based testing framework:
> https://hub.docker.com/_/mariadb/ (TestContainers also has a wrapper now for
> MariaDB:
> https://github.com/testcontainers/testcontainers-java/tree/master/modules/mariadb).
> Note that the MariaDB versions don’t match the MySQL versions.
FTR, I’ve tried adding support for MariaDB and it’s currently not working,
because of https://github.com/testcontainers/testcontainers-java/issues/949.
But we could provide a PR to them with not so big efforts or using a
GenericContainer (less nice).
Thanks
-Vincent
> * Should we drop support for MySQL?
>
> Thanks
> -Vincent
>
>> On 13 Nov 2018, at 11:50, Guillaume Delhumeau
>> wrote:
>>
>> Hello,
>>
>> We are in a weird situation where we don't say we support MariaDB but
>> "the latest
>> MySQL version of stable Debian repository", which is currently... MariaDB
>> [1]
>>
>> So we need to update our strategy about this fact. I am currently setting
>> up a server with debian 9 (stable) and I don't know if I should install
>> MySQL from the Oracle repository our continue with the standard debian
>> package (MariaDB).
>>
>> On my side, I am not against aligning ourself to debian. Basically, all
>> users installing XWiki with our Debian packages are using MariaDB for a
>> year now [2], and we never encounter any problem so far.
>>
>> Thanks,
>>
>> [1] https://packages.debian.org/stretch/default-mysql-server (dep:
>> mariadb-server-10.1)
>> [2] https://www.debian.org/News/2017/20170617.en.html
>>
>> Le lun. 12 nov. 2018 à 18:54, Thomas Mortagne a
>> écrit :
>>
>>> Indeed mysql-server package (version 5.5.) leads to
>>> mariadb-server-10.1 in current stretch repository.
>>>
>>> What is surprising is that this is not the case for sid which is more
>>> or less supposed to be the future. It's also not the case in Ubuntu
>>> which is doing the same thing as sid.
>>> On Mon, Nov 12, 2018 at 6:22 PM Eduard Moraru
>>> wrote:
I am not up to date on the topic, but I would like to add the fact that
Debian 9 ("stretch") has actually dropped MySQL and moved officially to
MariaDB, forcefully migrating existing MySQL installed versions to
>>> MariaDB.
>>> https://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.en.html#mariadb-replaces-mysql
The default mysql-server package now redirects to MariaDB instead.
If we are going to follow Debian's lead, we might want to at least
>>> consider
this move.
Thanks,
Eduard
On Mon, Nov 12, 2018 at 6:38 PM Vincent Massol
>>> wrote:
>
>
>> On 12 Nov 2018, at 16:52, Vincent Massol wrote:
>>
>> So we need to conclude on this thread. I’m proposing to update the
>>> page
> with:
>>
>> * HSQLDB - Latest only
>> * MySQL - latest of oldstable/stable/unstable from
>
>>> https://packages.debian.org/search?keywords=mysql-server=names=1
> (i.e. latest of 5.5.x and 5.7.x today)
>> * PostgreSQL - latest of oldstable/stable/unstable fromhttps://
> packages.debian.org/search?keywords=postgresql=names=1
> (i.e. latest of 9.4.x, 9.6.x and 11.x today)
>> * Oracle - latest of 12.x (we currently test on 11.x AFAIK so we
>>> need to
> start testing on 12.x from now on)
>>
>> Note that by “support" we mean test on. And it’s not because a
>>> version
> is not supported that it doesn’t work nor that we won’t fix it if a
>>> problem
> happens.
>>
>> I hesitated a long time for the mysql/pgsql versions since I wanted
>>> only
> a single version supported, but since we provide a debian packaging it
> makes sense to test the versions defined by the debian repos, and now
>>> that
> we have automated functional tests on various configurations, we can
>>> test
> on them. BTW I suggest we run all tests on the latest version only
>>> (i.e.
> 5.7.x for mysql and 11.x for postgresql, and move to mysql 8.x when we
>>> fix
> the bug on it) and then we do smoke tests on the other versions.
>>
>> Let me know quickly if you have a problem with this strategy since
>>> I’d
> like to update the page + add the configs in our CI tests.
>
> FYI, I’ve now updated the page at
> https://dev.xwiki.org/xwiki/bin/view/Community/DatabaseSupportStrategy
> (but I can update/revert if need be).
>
> Thanks
> -Vincent
>
>>
>> Thanks
>> -Vincent
>>
>>
>>> On 31 Oct 2018, at 09:06, Vincent Massol
>>> wrote:
>>>
>>> Hi devs,
>>>
>>> We currently have
> https://dev.xwiki.org/xwiki/bin/view/Community/DatabaseSupportStrategy
>>>
>>> However, it doesn’t say
Re: [xwiki-devs] [Proposal] Update database support strategy
There are 2 questions here:
* Should we add support for MariaDB? And if so which versions. Just found that
there’s an official docker image for it so it should be relatively easy to
support MariaDB in our docker-based testing framework:
https://hub.docker.com/_/mariadb/ (TestContainers also has a wrapper now for
MariaDB:
https://github.com/testcontainers/testcontainers-java/tree/master/modules/mariadb).
Note that the MariaDB versions don’t match the MySQL versions.
* Should we drop support for MySQL?
Thanks
-Vincent
> On 13 Nov 2018, at 11:50, Guillaume Delhumeau
> wrote:
>
> Hello,
>
> We are in a weird situation where we don't say we support MariaDB but
> "the latest
> MySQL version of stable Debian repository", which is currently... MariaDB
> [1]
>
> So we need to update our strategy about this fact. I am currently setting
> up a server with debian 9 (stable) and I don't know if I should install
> MySQL from the Oracle repository our continue with the standard debian
> package (MariaDB).
>
> On my side, I am not against aligning ourself to debian. Basically, all
> users installing XWiki with our Debian packages are using MariaDB for a
> year now [2], and we never encounter any problem so far.
>
> Thanks,
>
> [1] https://packages.debian.org/stretch/default-mysql-server (dep:
> mariadb-server-10.1)
> [2] https://www.debian.org/News/2017/20170617.en.html
>
> Le lun. 12 nov. 2018 à 18:54, Thomas Mortagne a
> écrit :
>
>> Indeed mysql-server package (version 5.5.) leads to
>> mariadb-server-10.1 in current stretch repository.
>>
>> What is surprising is that this is not the case for sid which is more
>> or less supposed to be the future. It's also not the case in Ubuntu
>> which is doing the same thing as sid.
>> On Mon, Nov 12, 2018 at 6:22 PM Eduard Moraru
>> wrote:
>>>
>>> I am not up to date on the topic, but I would like to add the fact that
>>> Debian 9 ("stretch") has actually dropped MySQL and moved officially to
>>> MariaDB, forcefully migrating existing MySQL installed versions to
>> MariaDB.
>>>
>>>
>> https://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.en.html#mariadb-replaces-mysql
>>>
>>> The default mysql-server package now redirects to MariaDB instead.
>>>
>>> If we are going to follow Debian's lead, we might want to at least
>> consider
>>> this move.
>>>
>>> Thanks,
>>> Eduard
>>>
>>> On Mon, Nov 12, 2018 at 6:38 PM Vincent Massol
>> wrote:
>>>
> On 12 Nov 2018, at 16:52, Vincent Massol wrote:
>
> So we need to conclude on this thread. I’m proposing to update the
>> page
with:
>
> * HSQLDB - Latest only
> * MySQL - latest of oldstable/stable/unstable from
>> https://packages.debian.org/search?keywords=mysql-server=names=1
(i.e. latest of 5.5.x and 5.7.x today)
> * PostgreSQL - latest of oldstable/stable/unstable fromhttps://
packages.debian.org/search?keywords=postgresql=names=1
(i.e. latest of 9.4.x, 9.6.x and 11.x today)
> * Oracle - latest of 12.x (we currently test on 11.x AFAIK so we
>> need to
start testing on 12.x from now on)
>
> Note that by “support" we mean test on. And it’s not because a
>> version
is not supported that it doesn’t work nor that we won’t fix it if a
>> problem
happens.
>
> I hesitated a long time for the mysql/pgsql versions since I wanted
>> only
a single version supported, but since we provide a debian packaging it
makes sense to test the versions defined by the debian repos, and now
>> that
we have automated functional tests on various configurations, we can
>> test
on them. BTW I suggest we run all tests on the latest version only
>> (i.e.
5.7.x for mysql and 11.x for postgresql, and move to mysql 8.x when we
>> fix
the bug on it) and then we do smoke tests on the other versions.
>
> Let me know quickly if you have a problem with this strategy since
>> I’d
like to update the page + add the configs in our CI tests.
FYI, I’ve now updated the page at
https://dev.xwiki.org/xwiki/bin/view/Community/DatabaseSupportStrategy
(but I can update/revert if need be).
Thanks
-Vincent
>
> Thanks
> -Vincent
>
>
>> On 31 Oct 2018, at 09:06, Vincent Massol
>> wrote:
>>
>> Hi devs,
>>
>> We currently have
https://dev.xwiki.org/xwiki/bin/view/Community/DatabaseSupportStrategy
>>
>> However, it doesn’t say explicitly which versions we officially
>> support:
>> * For HSQLDB it says 2.3.3 which is wrong since the latest version
>> is
2.4.1
>> * For MySQL it says 5.x but doesn’t specify which specific
>> version(s)
>> * Same for other DBs
>>
>> We cannot really support every versions since supporting means
>> testing
too.
>>
>> So what I propose:
>>
>> Question 1: definition
>>
>> * We say we support the latest stable
Re: [xwiki-devs] [Proposal] Update servlet container support strategy
On Tue, Nov 13, 2018 at 11:25 AM Vincent Massol wrote: > > So I’m proposing: > > * Tomcat: latest of debian oldstable/stable/unstable for tomcat 8.x, see > https://packages.debian.org/search?suite=default=all=any=names=tomcat8=1 > (in practice that’s 8.0.x and 8.5.x). > > @Thomas: I see that we provide a tomcat7 and tomcat8 packaging for debian. > Should we drop the tomcat7 one? I don’t think we should support it. Actually I have the need myself (some server stuck on a old Ubuntu 14.04 that I need to migrate) so I'm not going to delete it just yet :) But +1 to officially not support it yes. > > * Jetty: latest of debian oldstable/stable/unstable for jetty 9.x, see > https://packages.debian.org/search?suite=default=all=any=names=jetty9=1 > (in practice that’s 9.2.x). NOTE: Strange that “unstable” is lagging behind > so much and that Jetty 9.4.x is not being tested. Anyway it’s easier to > follow the debian repos. > > * Jetty Standaline: latest of Jetty 9.x, (i.e. 9.4.x FROM) > > I’m updating > https://dev.xwiki.org/xwiki/bin/view/Community/ServletContainerSupportStrategy/ > , let me know if you disagree. > > Thanks > -Vincent > > > On 31 Oct 2018, at 10:04, Vincent Massol wrote: > > > > Hi devs, > > > > We now have > > https://dev.xwiki.org/xwiki/bin/view/Community/ServletContainerSupportStrategy/ > > but it’s not precise enough. > > > > I’m proposing the following: > > > > * Mention the supported version cycle and mention that we support the > > latest version of the cycle. > > * For Tomcat, I propose to say we support Tomcat 8.x (which means Tomcat > > 8.5.34 as of today, see “latest” tag on https://hub.docker.com/_/tomcat/) > > * For Jetty (standalone packaging or standard), I propose to say we support > > Jetty 9.x (which means Jetty 9.4.12 as of today, see “latest” tag on > > https://hub.docker.com/_/jetty/) > > > > WDYT? > > > > Thanks > > -Vincent > > > > > -- Thomas Mortagne
Re: [xwiki-devs] [Proposal] Update database support strategy
Hello,
We are in a weird situation where we don't say we support MariaDB but
"the latest
MySQL version of stable Debian repository", which is currently... MariaDB
[1]
So we need to update our strategy about this fact. I am currently setting
up a server with debian 9 (stable) and I don't know if I should install
MySQL from the Oracle repository our continue with the standard debian
package (MariaDB).
On my side, I am not against aligning ourself to debian. Basically, all
users installing XWiki with our Debian packages are using MariaDB for a
year now [2], and we never encounter any problem so far.
Thanks,
[1] https://packages.debian.org/stretch/default-mysql-server (dep:
mariadb-server-10.1)
[2] https://www.debian.org/News/2017/20170617.en.html
Le lun. 12 nov. 2018 à 18:54, Thomas Mortagne a
écrit :
> Indeed mysql-server package (version 5.5.) leads to
> mariadb-server-10.1 in current stretch repository.
>
> What is surprising is that this is not the case for sid which is more
> or less supposed to be the future. It's also not the case in Ubuntu
> which is doing the same thing as sid.
> On Mon, Nov 12, 2018 at 6:22 PM Eduard Moraru
> wrote:
> >
> > I am not up to date on the topic, but I would like to add the fact that
> > Debian 9 ("stretch") has actually dropped MySQL and moved officially to
> > MariaDB, forcefully migrating existing MySQL installed versions to
> MariaDB.
> >
> >
> https://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.en.html#mariadb-replaces-mysql
> >
> > The default mysql-server package now redirects to MariaDB instead.
> >
> > If we are going to follow Debian's lead, we might want to at least
> consider
> > this move.
> >
> > Thanks,
> > Eduard
> >
> > On Mon, Nov 12, 2018 at 6:38 PM Vincent Massol
> wrote:
> >
> > >
> > >
> > > > On 12 Nov 2018, at 16:52, Vincent Massol wrote:
> > > >
> > > > So we need to conclude on this thread. I’m proposing to update the
> page
> > > with:
> > > >
> > > > * HSQLDB - Latest only
> > > > * MySQL - latest of oldstable/stable/unstable from
> > >
> https://packages.debian.org/search?keywords=mysql-server=names=1
> > > (i.e. latest of 5.5.x and 5.7.x today)
> > > > * PostgreSQL - latest of oldstable/stable/unstable fromhttps://
> > > packages.debian.org/search?keywords=postgresql=names=1
> > > (i.e. latest of 9.4.x, 9.6.x and 11.x today)
> > > > * Oracle - latest of 12.x (we currently test on 11.x AFAIK so we
> need to
> > > start testing on 12.x from now on)
> > > >
> > > > Note that by “support" we mean test on. And it’s not because a
> version
> > > is not supported that it doesn’t work nor that we won’t fix it if a
> problem
> > > happens.
> > > >
> > > > I hesitated a long time for the mysql/pgsql versions since I wanted
> only
> > > a single version supported, but since we provide a debian packaging it
> > > makes sense to test the versions defined by the debian repos, and now
> that
> > > we have automated functional tests on various configurations, we can
> test
> > > on them. BTW I suggest we run all tests on the latest version only
> (i.e.
> > > 5.7.x for mysql and 11.x for postgresql, and move to mysql 8.x when we
> fix
> > > the bug on it) and then we do smoke tests on the other versions.
> > > >
> > > > Let me know quickly if you have a problem with this strategy since
> I’d
> > > like to update the page + add the configs in our CI tests.
> > >
> > > FYI, I’ve now updated the page at
> > > https://dev.xwiki.org/xwiki/bin/view/Community/DatabaseSupportStrategy
> > > (but I can update/revert if need be).
> > >
> > > Thanks
> > > -Vincent
> > >
> > > >
> > > > Thanks
> > > > -Vincent
> > > >
> > > >
> > > >> On 31 Oct 2018, at 09:06, Vincent Massol
> wrote:
> > > >>
> > > >> Hi devs,
> > > >>
> > > >> We currently have
> > > https://dev.xwiki.org/xwiki/bin/view/Community/DatabaseSupportStrategy
> > > >>
> > > >> However, it doesn’t say explicitly which versions we officially
> support:
> > > >> * For HSQLDB it says 2.3.3 which is wrong since the latest version
> is
> > > 2.4.1
> > > >> * For MySQL it says 5.x but doesn’t specify which specific
> version(s)
> > > >> * Same for other DBs
> > > >>
> > > >> We cannot really support every versions since supporting means
> testing
> > > too.
> > > >>
> > > >> So what I propose:
> > > >>
> > > >> Question 1: definition
> > > >>
> > > >> * We say we support the latest stable version of the databases for a
> > > given version cycle
> > > >> ** For MySQL, it’s the latest of the 5.x cycle, which is 5.7.24 as
> of
> > > today (see https://hub.docker.com/_/mysql/)
> > > >> ** For PostgreSQL, it’s the latest of the 9.x cycle, which is
> 9.6.10
> > > as of today (see https://hub.docker.com/_/postgres/)
> > > >> ** For Oracle, it’s the latest of the 11.x cycle, which is
> 11.2.0.4.0
> > > as of today (see
> > >
> https://www.oracle.com/technetwork/database/enterprise-edition/downloads/index.html
> > > )
> > > >>
> > > >> Question 2: review what we support
> > > >>
> > > >>
Re: [xwiki-devs] [Proposal] Update servlet container support strategy
Forgot to mention that similar than for DBs, I plan to only add support for Tomcat 8.5.x latest and Jetty 9.2.x latest (+ Jetty 9.4.x latest for the standalone version) in the job running all the functional tests and run the other supported versions of tomcat in the job doing smoke tests. Thanks -Vincent > On 13 Nov 2018, at 11:25, Vincent Massol wrote: > > So I’m proposing: > > * Tomcat: latest of debian oldstable/stable/unstable for tomcat 8.x, see > https://packages.debian.org/search?suite=default=all=any=names=tomcat8=1 > (in practice that’s 8.0.x and 8.5.x). > > @Thomas: I see that we provide a tomcat7 and tomcat8 packaging for debian. > Should we drop the tomcat7 one? I don’t think we should support it. > > * Jetty: latest of debian oldstable/stable/unstable for jetty 9.x, see > https://packages.debian.org/search?suite=default=all=any=names=jetty9=1 > (in practice that’s 9.2.x). NOTE: Strange that “unstable” is lagging behind > so much and that Jetty 9.4.x is not being tested. Anyway it’s easier to > follow the debian repos. > > * Jetty Standaline: latest of Jetty 9.x, (i.e. 9.4.x FROM) > > I’m updating > https://dev.xwiki.org/xwiki/bin/view/Community/ServletContainerSupportStrategy/ > , let me know if you disagree. > > Thanks > -Vincent > >> On 31 Oct 2018, at 10:04, Vincent Massol wrote: >> >> Hi devs, >> >> We now have >> https://dev.xwiki.org/xwiki/bin/view/Community/ServletContainerSupportStrategy/ >> but it’s not precise enough. >> >> I’m proposing the following: >> >> * Mention the supported version cycle and mention that we support the latest >> version of the cycle. >> * For Tomcat, I propose to say we support Tomcat 8.x (which means Tomcat >> 8.5.34 as of today, see “latest” tag on https://hub.docker.com/_/tomcat/) >> * For Jetty (standalone packaging or standard), I propose to say we support >> Jetty 9.x (which means Jetty 9.4.12 as of today, see “latest” tag on >> https://hub.docker.com/_/jetty/) >> >> WDYT? >> >> Thanks >> -Vincent >> >> >
Re: [xwiki-devs] [Proposal] Update servlet container support strategy
Page updated at https://dev.xwiki.org/xwiki/bin/view/Community/ServletContainerSupportStrategy/ Thanks -Vincent > On 13 Nov 2018, at 11:25, Vincent Massol wrote: > > So I’m proposing: > > * Tomcat: latest of debian oldstable/stable/unstable for tomcat 8.x, see > https://packages.debian.org/search?suite=default=all=any=names=tomcat8=1 > (in practice that’s 8.0.x and 8.5.x). > > @Thomas: I see that we provide a tomcat7 and tomcat8 packaging for debian. > Should we drop the tomcat7 one? I don’t think we should support it. > > * Jetty: latest of debian oldstable/stable/unstable for jetty 9.x, see > https://packages.debian.org/search?suite=default=all=any=names=jetty9=1 > (in practice that’s 9.2.x). NOTE: Strange that “unstable” is lagging behind > so much and that Jetty 9.4.x is not being tested. Anyway it’s easier to > follow the debian repos. > > * Jetty Standaline: latest of Jetty 9.x, (i.e. 9.4.x FROM) > > I’m updating > https://dev.xwiki.org/xwiki/bin/view/Community/ServletContainerSupportStrategy/ > , let me know if you disagree. > > Thanks > -Vincent > >> On 31 Oct 2018, at 10:04, Vincent Massol wrote: >> >> Hi devs, >> >> We now have >> https://dev.xwiki.org/xwiki/bin/view/Community/ServletContainerSupportStrategy/ >> but it’s not precise enough. >> >> I’m proposing the following: >> >> * Mention the supported version cycle and mention that we support the latest >> version of the cycle. >> * For Tomcat, I propose to say we support Tomcat 8.x (which means Tomcat >> 8.5.34 as of today, see “latest” tag on https://hub.docker.com/_/tomcat/) >> * For Jetty (standalone packaging or standard), I propose to say we support >> Jetty 9.x (which means Jetty 9.4.12 as of today, see “latest” tag on >> https://hub.docker.com/_/jetty/) >> >> WDYT? >> >> Thanks >> -Vincent >> >> >
Re: [xwiki-devs] [Proposal] Update servlet container support strategy
So I’m proposing: * Tomcat: latest of debian oldstable/stable/unstable for tomcat 8.x, see https://packages.debian.org/search?suite=default=all=any=names=tomcat8=1 (in practice that’s 8.0.x and 8.5.x). @Thomas: I see that we provide a tomcat7 and tomcat8 packaging for debian. Should we drop the tomcat7 one? I don’t think we should support it. * Jetty: latest of debian oldstable/stable/unstable for jetty 9.x, see https://packages.debian.org/search?suite=default=all=any=names=jetty9=1 (in practice that’s 9.2.x). NOTE: Strange that “unstable” is lagging behind so much and that Jetty 9.4.x is not being tested. Anyway it’s easier to follow the debian repos. * Jetty Standaline: latest of Jetty 9.x, (i.e. 9.4.x FROM) I’m updating https://dev.xwiki.org/xwiki/bin/view/Community/ServletContainerSupportStrategy/ , let me know if you disagree. Thanks -Vincent > On 31 Oct 2018, at 10:04, Vincent Massol wrote: > > Hi devs, > > We now have > https://dev.xwiki.org/xwiki/bin/view/Community/ServletContainerSupportStrategy/ > but it’s not precise enough. > > I’m proposing the following: > > * Mention the supported version cycle and mention that we support the latest > version of the cycle. > * For Tomcat, I propose to say we support Tomcat 8.x (which means Tomcat > 8.5.34 as of today, see “latest” tag on https://hub.docker.com/_/tomcat/) > * For Jetty (standalone packaging or standard), I propose to say we support > Jetty 9.x (which means Jetty 9.4.12 as of today, see “latest” tag on > https://hub.docker.com/_/jetty/) > > WDYT? > > Thanks > -Vincent > >
Re: [xwiki-devs] [Need proposal] How to show "conflicting" macro parameters
Hello,
I'd like to briefly summarize the situation so that we can make some
progress.
What we have:
* We define "parameters" in a macro by creating a Java Bean, which
provides all the getters and setters of the parameters we want.
* We can use annotations on these getters/setters to define some
behavior or metadata for these parameters (description, mandatory,
deprecated...)
What we want:
* Being able to handle conflicting parameters. For instance when we
deprecate a parameter and add a new one to replace it, we should be
able to either use the deprecated parameter or the new one but not
both.
* We also want to group parameters that are related to each other.
What we proposed:
* Use annotations on the parameters to express the conflict.
* Marius proposed to see the problem as a boolean expression such as:
(page XOR (reference AND type) XOR document) OR section OR context.
This would translate as: the user can use the 'section' and/or
'context' parameters (if they want), can use only one of these
parameters: 'page', ('reference' and 'type') or 'document', where
'reference' and 'type' depend on each other and you can't use one
without the other.
* You can see on previous e-mails the kind of annotations we proposed
to solve the issue.
Thanks,
Adel
