> On 13 Apr 2019, at 12:59, Thomas Mortagne <thomas.morta...@xwiki.com> wrote:
>
> On Sat, Apr 13, 2019 at 11:39 AM Vincent Massol <vinc...@massol.net> wrote:
>>
>> Since it’s a vote I think I am -1 to support both Tomcat 8.x and 9.x at the
>> same level (I could change that to a -0 if everyone else agrees).
>>
>> For 2 reasons:
>> * I feel we’re don’t have enough agent power to support so many configs - we
>> already have too many IMO, and each new config increases the test time
>> exponentially.
>> * I’d really like that we continue having a single version for each infra
>> server in our docker-latest job.
>>
>> So I’m proposing one of the following 2 options:
>>
>> Option 1: Tomcat 8.x stays the supported version
>> =======
>>
>> * Continue delivering XWiki on Tomcat 8.x by default. For ex the Docker
>> image continue to be on Tomcat 8.x, see the tags on
>> https://hub.docker.com/_/xwiki?tab=description
>> * Offer a preview for Tomcat 9.x but don’t consider it as being officially
>> supported. This means mentioning the “preview” in the various docs.
>> * On the test side, this means adding it to docker-unsupported
>>
>> Option 2: Tomcat 9.x becomes the latest supported version
>> =======
>>
>> * Consider that Tomcat 9.x is now the latest version of Tomcat, i.e. make it
>> go in the docker-latest build (ie all tests execute on it). Executed daily.
>> * Consider that Tomcat 8.x is now an older version of Tomcat (but still
>> supported) and move all Tomcat 8.x tests to docker-all (ie only smoke tests
>> on it). Executed weekly.
>> * Upgrade the official Docker image to use Tomcat 9.x. More generally
>> upgrade all distributions to use Tomcat 9.x. Note that we support only 1
>> version of Tomcat in the Docker images we distribute.
>>
>> The only question I’m asking is whether Tomcat 9.x is stable enough for
>> using it in production vs Tomcat 8.x (8.5.x to be precise). Note that Tomcat
>> 8.5.x contains backports from Tomcat 9.x AFAIK and the main difference is
>> just the supported Servlet spec (AFAICS).
>>
>> So if we wish to make a move, I’d prefer option 2 but I don’t know if I know
>> enough about Tomcat 8.5.x vs Tomcat 9.x in production to make an educated
>> decision. I’d be curious to know if users would be ok to run Tomcat 9.x in
>> production. Now we would still support 8.5.x so users who want to stay on
>> Tomcat 8.5.x can.
>>
>> WDYT?
>>
>> Thanks
>> -Vincent
>>
>> PS: I thought I saw a jira issue being closed on this topic, did I dream it
>> or did you anticipate the vote results? ;)
>
> Providing a Debian package which work with Tomcat 9 does not make it
> officially supported as you said.
For me it kind of does because I don’t see how we would officially provide a
package and not test it (and if we test it then it’s officially supported).
Unless we explicitly mark is as experimental so that users know that it’s not
supported when they use it.
Thanks
-Vincent
>
>>
>>> On 12 Apr 2019, at 17:53, Thomas Mortagne <thomas.morta...@xwiki.com> wrote:
>>>
>>> On Fri, Apr 12, 2019 at 5:42 PM Vincent Massol <vinc...@massol.net> wrote:
>>>>
>>>>
>>>>
>>>>> On 12 Apr 2019, at 17:35, Thomas Mortagne <thomas.morta...@xwiki.com>
>>>>> wrote:
>>>>>
>>>>> On Fri, Apr 12, 2019 at 5:07 PM Vincent Massol <vinc...@massol.net> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On 12 Apr 2019, at 17:00, Thomas Mortagne <thomas.morta...@xwiki.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hi devs,
>>>>>>>
>>>>>>> tomcat9 package is now available in Debian repositories so I would
>>>>>>> like to start providing xwiki-tomcat9-* Debian packages of XWiki.
>>>>>>>
>>>>>>> Nothing complex so far but it if we provide an official tomcat 9
>>>>>>> oriented package it would also make more sense to add Tomcat 9 in
>>>>>>> https://dev.xwiki.org/xwiki/bin/view/Community/SupportStrategy/ServletContainerSupportStrategy/
>>>>>>> (only Tomcat 8 right now).
>>>>>>>
>>>>>>> Another argument is that it's the current recommended stable version
>>>>>>> from Tomcat point of view so people will use it more and more.
>>>>>>>
>>>>>>> WDYT ?
>>>>>>
>>>>>> In principle it’s good but it means doing a lot more tests to officially
>>>>>> support it and we’re already doing a lot. So I’m not very inclined to
>>>>>> add new config tests. It adds a lot of hours to the build. I’d prefer
>>>>>> that we keep officially supporting only a single version if we can. Same
>>>>>> as for jetty for ex.
>>>>>>
>>>>>> BTW could you provide the URLs for the various debian repos (oldstable,
>>>>>> stable, unstable) so that we can check the precise Tomcat versions?
>>>>>
>>>>> https://packages.debian.org/search?keywords=tomcat9 so 9.0.16. It's
>>>>> available in the stable branch trough backport repository (stable
>>>>> branch never get new major version directly).
>>>>
>>>> So it seems there’s only an “unstable” version FTM. I would wait till
>>>> there’s a “stable” version at least. We could add it to our “unsupported”
>>>> docker tests that execute once a month though. WDYT?
>>>
>>> No as I said there is a stable package, you just have to enable stable
>>> backports. There is also a testing version.
>>>
>>>>
>>>> What’s your need for adding support for it now, since debian doesn’t have
>>>> a stable support for it yet?
>>>>
>>>>>
>>>>>> BTW I also noticed that https://packages.debian.org/sid/tomcat8 doesn’t
>>>>>> exist anymore. It’s been removed? This link is in our doc at
>>>>>> https://dev.xwiki.org/xwiki/bin/view/Community/SupportStrategy/ServletContainerSupportStrategy/
>>>>>
>>>>> This is the URL for sid only which is the unstable branch. Not really
>>>>> sure if it's like this on purpose or if it's a mistake but it will
>>>>> continue to be available for a very long time in the stable branch for
>>>>> sure anyway. On Tomcat side there is no date announced for 8.5.x end
>>>>> of life.
>>>>
>>>> This link used to work so it’s been removed. Not sure what we should do.
>>>>
>>>> Thanks
>>>> -Vincent
>>>>
>>>>>
>>>>>>
>>>>>> Thanks
>>>>>> -Vincent
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Here is my +1
>>>>>>> --
>>>>>>> Thomas Mortagne
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Thomas Mortagne
>>>>
>>>
>>>
>>> --
>>> Thomas Mortagne
>>
>
>
> --
> Thomas Mortagne
