Ok. Sounds good. I won't change the version number (leave at 5.0-SNAPSHOT). I will go back and update fulcrum/turbine dependencies to serlet-api 3.1, as well as the archetype and make sure at least everything I have done is in alignment with this plan.
We can update torque when it is ready :-) Just noticed the difference in the feather logo on velocity versus turbine... it looks much improved! Thanks! Jeff On 10/09/2018 09:49 AM, Georg Kallidis wrote: > yes, and consider > https://httpd.apache.org/security/vulnerabilities_24.html, if you are > using Apache web server .. > > we not necessarily must go back to Turbine version 4.1, although it might > be mapping well Torque 4.1, we should stay with current 5.x version number > IMO (and just reverting only one single revision), as we make in the > Turbine project itself some major step (with java 8, velocity 2.0 and > servlet 3.1). Of course, explaining this more on the web site would have > its own efforts and values (BTW we should updte the feather logo as soon > as possible). > > But I am not sure, if we should wait for a Torque 4.1 release. I think, > what I could do best now is to upgrade some Fulcrums - where needed - and > test Turbine-Webapp - check Turbine, what might be missing already now. > Releases could then be done relying only on what we could achieve > ourselfes in Turbine now. Afterwards a Torque release would indeed be > worth another Fulcrum Security,Turbine release then! > > Best regards, Georg > > > > Von: Jeffery Painter <[email protected]> > An: [email protected] > Datum: 09.10.2018 14:31 > Betreff: Re: Preparing for releases? > > > > Hi Georg, > > I am in agreement. Maybe we take the approach of doing a proper > Turbine 4.1 release (convenient mapping to a Torque 4.1 release) and > keep all the changes so far except downgrading back to servlet 3.1. The > good news is moving to servlet-api 4.0 is proven out, and does not > require much more than updating the dependencies and adding in the > implementation methods into the Turbine servlet and context configuration. > > My reasons are along the same line of thought @tomcat9 - none of the > debian based linux distros yet have a package for tomcat9. I personally > prefer using a package manager to handle installation of tomcat on my > servers. It just gives me one less thing to worry about. > > And it would put a burden on those who aren't as comfortable downloading > a tomcat distro and setting it up themselves to get started. There is > work finally going on in debian to create a tomcat9 package, but who > knows when it will be released, and due to many dependency requirements, > I could not even get it to build in Ubuntu 18.04 LTS. I had to setup a > VM with debian/buster (testing version) to get a working package. This > is too much to ask of general public :-) > > Then we can hold off a turbine-5.0 release until tomcat9 is more readily > available, or we could go ahead and start turbine-5.0 with > docker/container images so we can handle the tomcat9 setup and config > ourselves. > > I also agree with release plan: > 1. Update torque-4.1 > 2. fulcrum components (use that time to decide which ones can now be > marked dormant, give Georg time to update JSON) > 3. turbine-4.1 and turbine-webapp-4.1 > > Then we move turbine-5.0 to servlet-api 4 spec. Of course, I need help > getting torque-4.1 integrated. I ran into some difficulties there which > were beyond me as I am not really familiar with that code base as much. > > If you want, I can go ahead and start updating my turbine changes in > trunk to be "turbine-4.1" release and change the dependencies all back > down to servlet-api-3.1 > > Just let me know what you guys want. > > Thanks! > > - > Jeff > > > > On 10/09/2018 04:47 AM, Georg Kallidis wrote: >> .. sorry, this was not yet completed! >> >> I appreciate all the things you have done A LOT (very excited about your >> lightning talk !!), still reviewing... >> >> @turbine-archetype: I 'll test it as soon as possible. We might add a >> .gitattributes to get rid of eol issues. The proposed Docker branch is >> still not yet completed, but if required I could check in the current >> state.. >> >> @fulcrums: Currently I have some changes in Fulcrum JSON, which I 'll >> check in soon and @releases: We might have to release Fulcrum components >> before Turbine 5 release? And (this might be better) before releasing >> Fulcrum Security wait for a Torque 4.1 release? >> >> And about the implications of Servlet API 4 - practically it would > require >> Tomcat 9). Might there be any option to allow for Servlet 3.1 (does it >> make sense)? >> >> Best regards, Georg >> >> >> >> >> Von: "Georg Kallidis" <[email protected]> >> An: "Turbine Developers List" <[email protected]> >> Datum: 09.10.2018 09:34 >> Betreff: Re: Preparing for releases? >> >> >> >> Hi Jeff, I am >> >> .... >> >> >> Von: Jeffery Painter <[email protected]> >> An: Turbine Developers List <[email protected]> >> Datum: 08.10.2018 22:13 >> Betreff: Preparing for releases? >> >> >> >> >> So, you can see I have been busy. And I went back through the email >> archives and figured out how Georg had setup the archetype in apache >> gitbox. I merged my changes (forgive me Georg, but I get annoyed with >> line breaks that were built on MS machines - the diff was pretty large >> using dos2unix to convert them all, but I did merge your changes with >> mine before pushing up :-) ). >> >> Here is the merge of Georg's changes to archetype with Jeff's version if >> you want an easy review: >> > https://github.com/jlpainter/turbine-webapp-5.0/commit/d1282ed29a4029ecdd6246cd1f3c232d66c26d29 > >> >> >> I went through the Turbine fulcrum dependencies, updated findbugs where >> I could (there is still one in the equals method that I couldn't find a >> workaround for) and a few others. I mostly ignored those in test >> cases. fulcrum-pool had some nested classes that I refactored out to >> try and resolve a lot of the type checking issues going on. All the >> test cases are passing, but I am open to criticism if you disagree with >> my changes there. >> >> I still need to go back and identify those fulcrum components which >> should likely be marked dormant. I may have gotten over zealous with my >> global replace (I noticed several proposal/extension classes got updates >> that probably shouldn't, but I think it is mostly dead code). >> >> Please please let me know if I have overstepped anywhere. I want to be a >> good committer and not offend anyone :-) >> >> All that being said, I am pretty happy with the current state. I >> participated in the key signing event at ApacheCon that Jean-Frederic >> held, and I finally have my key authenticated by a few others who >> attended (published to keyring, in the pgp.mit.edu server, etc). >> >> I think the next step is for me to go back and re-read Georg's emails >> about preparing a release and start issuing some vote requests. Any help >> here would be appreciated.... I am guessing from Georg's silence the >> past 2 weeks he is out, but I am happy to wait until all are available >> to do a review of the updates I have made before proposing any votes. >> >> Let me know what you think. I am so happy I could finally contribute >> back (in hopefully a meaningful way), and if there are any other items >> you think we should check off before doing an initial 5.0 release, I am >> happy to help. I know we will need some work on the website... I think >> it is in a pretty messy state. I could spend some time on that as well. >> It could certainly use some simplification. >> >> Best, >> > > [Anhang "signature.asc" gelöscht von Georg Kallidis/CeDiS/FU-Berlin/DE] >
signature.asc
Description: OpenPGP digital signature
