As mentionned tomcat 8.0 EOL has been announced, here is the interesting part of it:
" The Apache Tomcat team announces that support for Apache Tomcat 8.0.x will end on 30 June 2018. This means that after 30 June 2018: - releases from the 8.0.x branch are highly unlikely - bugs affecting only the 8.0.x branch will not be addressed - security vulnerability reports will not be checked against the 8.0.x branch Three months later (i.e. after 30 September 2017) - the 8.0.x download links will be removed - the latest 8.0.x release will be removed from the mirror system - the 8.0.x branch in svn will move from /tomcat/tc8.0.x to /tomcat/archive/tc8.0.x - the links to the 8.0.x documentation will be removed from tomcat.apache.org " We are already on 8.5 so not directly impacted for 7.x but think we can take it as a good example for 1.x. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://blog-rmannibucau.rhcloud.com> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory <https://javaeefactory-rmannibucau.rhcloud.com> 2017-06-19 16:14 GMT+02:00 Romain Manni-Bucau <[email protected]>: > > > 2017-06-19 16:04 GMT+02:00 Jonathan Gallimore < > [email protected]>: > >> Firstly, I note the page Romain started - thank you for listening to my >> feedback. I'd be happy to test instructions and contribute to that page. I >> suspect some DBCP(2) settings are different so we should call those out. >> I'll also try and help build it out into a step by step guide. >> > > Hmm, database pool can need there own thread but current doc basically > says "read the pool doc" cause each time we copied it, we ended up messing > more than solving in term of user experience so I'm not sure we should do > this exercise. That said +1 to add a point saying it should be validated. > Tomcat pool being the default we shouldn't be too much affected in "prod". > > >> >> Secondly, I have been thinking about the EOL. I personally really dislike >> the term 'End of life' for an Open Source project / branch. The branch >> will >> ultimately live on while there are committers / contributors whether >> individual or organizations that are prepared to provide patches. The >> OpenEJB Eclipse Plugin could be thought of as "End Of Life", but if >> someone >> showed up on the mailing list wanting to use it with the latest version of >> Eclipse, and it didn't work (which I expect is the case), or found a bug, >> truthfully, I would be simply delighted to update it - so in that regard >> it >> isn't EOL. >> > > Agree but think not using EOL would be misleading. What we want is to: > > 1. show 1.x is not more active > 2. 1.x is no more maintained (and once again this is not linked to our > only will in term of OS ecosystem) > 3. you should migrate to 7 > > I'm fine detailling it in the announce but not sure if using a more > accurate term (EOS - end of support ?) wouldn't be more misleading :s > > >> >> Similarly, if someone / an organization wanted to contribute and maintain >> 1.7.x, then there shouldn't really be any blocker to them doing so, and >> therefore it also wouldn't be EOL. >> > > Well the OS side is a blocker. This means 1.x needs to live with a tons of > fork which should be ack by tomee project before being an option. > > >> >> I do, however, appreciate that there is a desire for people to migrate to >> the latest version, as there is more activity there in terms of later >> specs >> and new functionality, and I also appreciate the issue where dependencies >> 1.7.x uses may not be updated any more. >> >> I'd like to make the suggestion that we give an honest statement about >> each >> version available, in order to help facilitate decision making. As to what >> "honest statement" means... well I think we'd need to discuss and agree >> the >> specific statements. Off the top of my head, it could be something like: >> >> Pre-1.7.x: No longer being updated within the community. >> 1.7.x: Stable, certified, supports Java EE 6 Web Profile. Receives >> security >> fixes, occasional feature updates and backports, and bug fixes. Last >> commit: yyyy-MM-dd, last release: yyyy-MM-dd. N.B. some dependencies (e.g. >> <list here>) no longer receive updates. Consider upgrading to 7.0, see the >> migration guide here: http://tomee.apache.org/........ >> 7.x: Stable, GA, supports Java EE 7 Web Profile. Actively developed, >> receives security fixes, numerous feature updates and bug fixes. Last >> commit: yyyy-MM-dd, last release: yyyy-MM-dd >> 8.x: In progress, not yet GA, supports Java EE 8 Web Profile. Consider >> this >> to be ahead of "bleeding edge". Last commit: yyyy-MM-dd, last release: >> yyyy-MM-dd >> >> > Hmm, this looks really awesome and close to what we should go with IMHO > but experience shows it is not as reliable as it is written to. Maybe we > should rephrase it more in a way saying "maintained as best effort allows > and when some companies want, will be EOL [next year]" - "EOL" and "next > year" to replace by this thread outcome indeed. > > What I want to avoid here is the understanding 1.7 will get backports or > security fixes systematically which never have been the case - not blaming > since I'm a lot responsible of it but just trying to be realistic with our > resources. > > >> Thoughts? >> >> Jon >> >> On Mon, Jun 19, 2017 at 2:42 PM, Andy Gumbrecht <[email protected] >> > >> wrote: >> >> > -1 >> > >> > I would welcome an EOL announcement at the end of the year (with a years >> > notice), but not right now. That's too much pressure. So to make that >> > clear, I would announce EOL on the 1st Jan.18 and EOL is then 1st Jan >> 2019 >> > - That gives everyone plenty of time to create detailed documentation on >> > the site that targets everyone, and then plenty of time to migrate. >> > >> > We could make a pre-EOL announcement that details the above plan. An >> > announcement of the planned announcement so to say - That would enable >> > contribution and discussion regarding the EOL effort by the community >> > rather than being a snap decision. >> > >> > Andy. >> > >> > On 18 June 2017 at 20:36, Romain Manni-Bucau <[email protected]> >> > wrote: >> > >> > > http://tomee.apache.org/developer/migration/tomee-1-to-7.html >> intends to >> > > solve that issue, we can add any point we hit/encounter >> > > >> > > what else would be a blocker to make 1 EOL in June 2018? >> > > >> > > >> > > Romain Manni-Bucau >> > > @rmannibucau <https://twitter.com/rmannibucau> | Blog >> > > <https://blog-rmannibucau.rhcloud.com> | Old Blog >> > > <http://rmannibucau.wordpress.com> | Github <https://github.com/ >> > > rmannibucau> | >> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory >> > > <https://javaeefactory-rmannibucau.rhcloud.com> >> > > >> > > 2017-06-18 20:17 GMT+02:00 Romain Manni-Bucau <[email protected] >> >: >> > > >> > > > >> > > > >> > > > 2017-06-18 19:50 GMT+02:00 Mark Struberg <[email protected] >> >: >> > > > >> > > >> regarding migration. >> > > >> There are 3 different main use cases afaict. >> > > >> 1.) TomEE standalone server, quite like Tomcat. Using 7.x instead >> > 1.7.x >> > > >> should be a no-brainer without any need to change something within >> > your >> > > >> application >> > > >> >> > > >> 2.) tomee-maven-plugin: change the groupId from org.apache.openejb >> to >> > > >> org.apache.tomee. Done >> > > >> >> > > > >> > > > >> > > > >> > > > >> > > >> 3.) openejb-core for unit tests. This gets a bit trickier as the >> > various >> > > >> spec APIs from EE7 (tomee) and EE6 (your application) might clash. >> > This >> > > can >> > > >> be solved with an exclude setting in the maven-surefire-plugin >> > > >> >> > > > >> > > > Hmm, just means we upgrade API or you think to something else? >> > > > >> > > > I'll start a page >> > > > >> > > > >> > > >> LieGrue,strub >> > > >> >> > > >> >> > > >> On Sunday, 18 June 2017, 18:51, Romain Manni-Bucau < >> > > >> [email protected]> wrote: >> > > >> >> > > >> >> > > >> 2017-06-18 18:42 GMT+02:00 Jonathan Gallimore < >> > > [email protected] >> > > >> >: >> > > >> >> > > >> > Thanks for the feedback. I think at least some sort of migration >> > guide >> > > >> is >> > > >> > needed as some settings have changed. It would be nice for >> people to >> > > >> find >> > > >> > out the easy way. Happy to discuss in another thread, but we >> should >> > > >> agree >> > > >> > when this will appear. >> > > >> > >> > > >> >> > > >> Which settings are you thinking about? >> > > >> >> > > >> >> > > >> > >> > > >> > I also think some visibility on what the EOL statement will >> actually >> > > >> say (I >> > > >> > guess it would be a paragraph or two) would help community >> > discussion. >> > > >> > >> > > >> >> > > >> No more expectation from the core community (releases etc). So >> > > evolutions >> > > >> as best effort (no guarantee). >> > > >> >> > > >> >> > > >> > >> > > >> > I suspect you won't agree, but I think an EOL is a major >> > > announcement. A >> > > >> > reminder is good if the thread has gone quiet, but I think lazy >> > > >> concensus >> > > >> > is less good, unless several reminders have been sent. You have >> > > stated a >> > > >> > deadline of today, a Sunday - I think some folks may miss that >> and >> > be >> > > >> too >> > > >> > late. I think mid week would be better to reduce the scope of >> > "missing >> > > >> it". >> > > >> > If we got to mid week, and had a couple more reminders, the lazy >> > > >> concensus >> > > >> > view would seem more reasonable. >> > > >> > >> > > >> > Wouldn't you prefer to make the EOL statement with a few more >> +1's? >> > > >> > >> > > >> >> > > >> Sure, now i used past releases as prevision of this topic activity >> > > >> plannification and even with 5 reminders i wouldnt have got more so >> > > >> preferring to move forward now. However as said I'm happy to >> discuss >> > > each >> > > >> points and delay what was just a proposal. >> > > >> >> > > >> >> > > >> > >> > > >> > Jon >> > > >> > >> > > >> > On 18 Jun 2017 5:06 pm, "Romain Manni-Bucau" < >> [email protected] >> > > >> > > >> > wrote: >> > > >> > >> > > >> > > 2017-06-18 17:36 GMT+02:00 Jonathan Gallimore < >> > > >> > > [email protected]> >> > > >> > > : >> > > >> > > >> > > >> > > > On 18 Jun 2017 3:11 pm, "Romain Manni-Bucau" < >> > > [email protected] >> > > >> > >> > > >> > > > wrote: >> > > >> > > > >> > > >> > > > @Jon: please propose a policy then (same as rejecting a >> release, >> > > >> "no" >> > > >> > is >> > > >> > > > valid only if an alternative is proposed or a string blocker >> is >> > > >> found >> > > >> > > ;)). >> > > >> > > > >> > > >> > > > >> > > >> > > > I feel I stated my concerns pretty clearly. I didn't just >> reply >> > -1 >> > > >> and >> > > >> > > walk >> > > >> > > > away, which is what your comment above is suggesting I did. >> > > >> > > > >> > > >> > > >> > > >> > > Ok then understand it as i dont read it as an exit path for the >> > > >> project. >> > > >> > > >> > > >> > > >> > > >> > > > >> > > >> > > > But, allow me to rephrase anyway - beyond a "drop dead" date, >> > what >> > > >> > > exactly >> > > >> > > > is your policy? >> > > >> > > > >> > > >> > > > How many releases do you see in that time? >> > > >> > > > >> > > >> > > >> > > >> > > As much as needed - up to request. Concretely if no user asks >> for >> > it >> > > >> no >> > > >> > > release, if users ask each month then ~12 (pby more ~10 >> > > realisticly), >> > > >> not >> > > >> > > sure we would do more but sounds way more than enough. It is in >> > > >> > > maintainance anyway so "when needed". >> > > >> > > >> > > >> > > >> > > >> > > > >> > > >> > > > What documentation for migration are we going to provide? >> > > >> > > > >> > > >> > > >> > > >> > > Any doc needed but have to admit no doc should be needed. This >> is >> > > >> quite >> > > >> > > parallel to this track so if you see any lack please open a >> thread >> > > and >> > > >> > > we'll solve it. >> > > >> > > >> > > >> > > >> > > >> > > > >> > > >> > > > Do we still intend to fix bugs and/or security issues after >> that >> > > >> date? >> > > >> > > > >> > > >> > > >> > > >> > > No, EOL is exactly that: this soft is no more part of active >> code >> > > >> after >> > > >> > the >> > > >> > > date. >> > > >> > > >> > > >> > > Side note: already the case since few years actually if you >> check >> > > our >> > > >> > jira >> > > >> > > :(. >> > > >> > > >> > > >> > > >> > > >> > > > >> > > >> > > > Would we continue to accept patches from the community after >> > that >> > > >> date? >> > > >> > > > >> > > >> > > >> > > >> > > In best effort mode so no engagement but i dont see why we >> > wouldnt. >> > > >> Maybe >> > > >> > > something unclear: source will not be modified, moved, put read >> > only >> > > >> > > etc...just releases and maintainance is no more expectable from >> > > tomee >> > > >> > > project itself. >> > > >> > > >> > > >> > > >> > > >> > > > >> > > >> > > > Your plan basically is to just stop, if I have read it >> > correctly. >> > > I >> > > >> > have >> > > >> > > > concerns about that, which I have stated. >> > > >> > > > >> > > >> > > >> > > >> > > I understand but it was to stop *next year* and we need a plan >> > > anyway. >> > > >> > 1.7 >> > > >> > > has several important issues due to the non maintainance it >> gets >> > > >> since > >> > > >> > 2 >> > > >> > > years. >> > > >> > > >> > > >> > > >> > > >> > > > >> > > >> > > > My proposal is simple; answer the questions and concerns >> about >> > > your >> > > >> > > > proposal and discuss it fully within the community rather >> than >> > > >> announce >> > > >> > > > something on the website with a single +1. I don't think >> that is >> > > >> > > > unreasonable. >> > > >> > > > >> > > >> > > >> > > >> > > Was not the idea, as stated in the topic it was a discussion >> but >> > no >> > > >> > > activity in > 10 days requires to take an action, either ack >> it by >> > > >> > default >> > > >> > > or .... well I don't see any alternative to take the active >> > > feedback. >> > > >> > Happy >> > > >> > > you catch up it now Jon and let's discuss based on previous >> > points - >> > > >> as >> > > >> > > this thread was intended for. >> > > >> > > >> > > >> > > >> > > >> > > > >> > > >> > > > Jon >> > > >> > > > >> > > >> > > > >> > > >> > > > Realisticly 1.7 is no more maintained (the cxf coming >> > exceptional >> > > >> > release >> > > >> > > > doesn't help since all the stack is outdated now and coming >> to >> > EOL >> > > >> and >> > > >> > > > reactivity is too long - we have > 100 bugs we don't backport >> > but >> > > >> > affect >> > > >> > > > 1.7). >> > > >> > > > The upgrade path is really a noop on our side thanks to >> javaee >> > > >> policy. >> > > >> > If >> > > >> > > > you are thinking about something in particular happy to add >> it >> > on >> > > >> the >> > > >> > > site. >> > > >> > > > >> > > >> > > > EOL doesn't mean we don't release, we can literally do 120 >> > > releases >> > > >> of >> > > >> > > > 1.7.x if we ack the proposed EOL. >> > > >> > > > >> > > >> > > > >> > > >> > > > Romain Manni-Bucau >> > > >> > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog >> > > >> > > > <https://blog-rmannibucau.rhcloud.com> | Old Blog >> > > >> > > > <http://rmannibucau.wordpress.com> | Github < >> > https://github.com/ >> > > >> > > > rmannibucau> >> > > >> > > > | >> > > >> > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE >> > > Factory >> > > >> > > > <https://javaeefactory-rmannibucau.rhcloud.com> >> > > >> > > > >> > > >> > > > 2017-06-18 15:43 GMT+02:00 Mark Struberg >> > > <[email protected] >> > > >> >: >> > > >> > > > >> > > >> > > > > So probably one more 1.7.x release and then let it fade >> out? >> > > >> > > > > >> > > >> > > > > LieGrue, >> > > >> > > > > strub >> > > >> > > > > >> > > >> > > > > >> > > >> > > > > >> > > >> > > > > > Am 18.06.2017 um 13:55 schrieb Jonathan Gallimore < >> > > >> > > > > [email protected]>: >> > > >> > > > > > >> > > >> > > > > > I object. There are plenty of folks still using 1.7.x, >> and >> > > we've >> > > >> > > ported >> > > >> > > > > > over various fixes from master without too much trouble. >> > > >> > > > > > >> > > >> > > > > > My concern is that those on 1.7.x might be concerned to >> see >> > it >> > > >> > EOL'd. >> > > >> > > > I'd >> > > >> > > > > > like to see the upgrade path documented and a policy on >> > fixes >> > > >> > applied >> > > >> > > > to >> > > >> > > > > > 1.7.x documented and discussed before an EOL >> announcement. >> > > >> > > > > > >> > > >> > > > > > Jon >> > > >> > > > > > >> > > >> > > > > > On 18 Jun 2017 10:51 am, "Romain Manni-Bucau" < >> > > >> > [email protected] >> > > >> > > > >> > > >> > > > > wrote: >> > > >> > > > > > >> > > >> > > > > >> if noone objects before tomorrow i'll update the site >> with >> > > that >> > > >> > > policy >> > > >> > > > > >> then. >> > > >> > > > > >> >> > > >> > > > > >> >> > > >> > > > > >> Romain Manni-Bucau >> > > >> > > > > >> @rmannibucau <https://twitter.com/rmannibucau> | Blog >> > > >> > > > > >> <https://blog-rmannibucau.rhcloud.com> | Old Blog >> > > >> > > > > >> <http://rmannibucau.wordpress.com> | Github < >> > > >> https://github.com/ >> > > >> > > > > >> rmannibucau> | >> > > >> > > > > >> LinkedIn <https://www.linkedin.com/in/rmannibucau> | >> > JavaEE >> > > >> > Factory >> > > >> > > > > >> <https://javaeefactory-rmannibucau.rhcloud.com> >> > > >> > > > > >> >> > > >> > > > > >> 2017-06-17 21:55 GMT+02:00 Mark Struberg >> > > >> > <[email protected] >> > > >> > > >: >> > > >> > > > > >> >> > > >> > > > > >>> +1. >> > > >> > > > > >>> >> > > >> > > > > >>> 1.x has quite a few design shortcomings and 7.0.x is a >> > > >> backward >> > > >> > > > > >> compatible >> > > >> > > > > >>> drop in replacement. >> > > >> > > > > >>> And 8.x is just around the corner as well... >> > > >> > > > > >>> >> > > >> > > > > >>> LieGrue, >> > > >> > > > > >>> strub >> > > >> > > > > >>> >> > > >> > > > > >>> >> > > >> > > > > >>>> Am 06.06.2017 um 17:58 schrieb Romain Manni-Bucau < >> > > >> > > > > >> [email protected] >> > > >> > > > > >>>> : >> > > >> > > > > >>>> >> > > >> > > > > >>>> Hi guys, >> > > >> > > > > >>>> >> > > >> > > > > >>>> it is harder and harder to maintain 1.x branch since >> > almost >> > > >> no >> > > >> > > > library >> > > >> > > > > >> is >> > > >> > > > > >>>> maintained. Request is also decreasing for that >> version. >> > > >> Tomcat >> > > >> > > will >> > > >> > > > > >> also >> > > >> > > > > >>>> EOL tomcat 8 next year (1.x is on tomcat 7 which still >> > dont >> > > >> have >> > > >> > > an >> > > >> > > > > >>>> official EOL I think but never good to rely on an >> > outdated >> > > >> > > version, >> > > >> > > > > >>> Tomcat >> > > >> > > > > >>>> 7 is N-3 now). >> > > >> > > > > >>>> >> > > >> > > > > >>>> Therefore do we want to plan an EOL for 1.7 that we >> don't >> > > >> > develop >> > > >> > > > > >> anymore >> > > >> > > > > >>>> anyway? What about june next year? Should let people >> more >> > > >> than >> > > >> > > > enough >> > > >> > > > > >>> time >> > > >> > > > > >>>> to migrate to TomEE 7. >> > > >> > > > > >>>> >> > > >> > > > > >>>> wdyt? >> > > >> > > > > >>>> >> > > >> > > > > >>>> Romain Manni-Bucau >> > > >> > > > > >>>> @rmannibucau <https://twitter.com/rmannibucau> | >> Blog >> > > >> > > > > >>>> <https://blog-rmannibucau.rhcloud.com> | Old Blog >> > > >> > > > > >>>> <http://rmannibucau.wordpress.com> | Github < >> > > >> > https://github.com/ >> > > >> > > > > >>> rmannibucau> | >> > > >> > > > > >>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | >> > > JavaEE >> > > >> > > Factory >> > > >> > > > > >>>> <https://javaeefactory-rmannibucau.rhcloud.com> >> > > >> > > > > >>> >> > > >> > > > > >>> >> > > >> > > > > >> >> > > >> > > > > >> > > >> > > > > >> > > >> > > > >> > > >> > > >> > > >> > >> > > >> >> > > >> >> > > >> >> > > >> >> > > > >> > > > >> > > >> > >> > >> > >> > -- >> > Andy Gumbrecht >> > https://twitter.com/AndyGeeDe >> > http://www.tomitribe.com >> > >> > >
