Hi folks, I’m sorry for digging back this old thread.
I think we never ended up making a decision on this, and a year and a half as passed since we discussed this. So, I would like to bring to the table again the discussion around supporting TomEE 1.x and EOL. Cheers, Roberto > On 30 Jun 2017, at 22:34, Romain Manni-Bucau <[email protected]> wrote: > > 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 >>>> >>> >> >>
