BTW just noticed that we still have 
https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-distribution/xwiki-platform-distribution-debian/xwiki-platform-distribution-debian-tomcat/xwiki-platform-distribution-debian-tomcat7-mysql/pom.xml

However we don’t support Tomcat 7.x officially AFAIK (it’s not on 
https://dev.xwiki.org/xwiki/bin/view/Community/SupportStrategy/ServletContainerSupportStrategy/
 ).

Note that we don’t have any tests executing on Tomcat 7.x ATM.

Shouldn’t we remove it?

Thanks
-Vincent

> On 13 Apr 2019, at 11:39, 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? ;)
> 
>> 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
> 

Reply via email to