I guess a manual process will still be needed in order to turn any kind of automated build into an official stable version, unless automated test are covering 100% of potential regressions (wild dream, I guess:) ).
My question about TomEE / TomEE+ upgrade process is meant to (when it'll be solved) make newcomers comfortable with TomEE / TomEE+. Security isn't an option, and today's public pages aren't giving a clear view of the relationships between TomEE / TomEE+ version and Tomcat version. A first improvement could be to include a small version matrix of all included components for a given TomEE / TomEE+ version Another improvement could be to give a roadmap of version updates. Alex On Tue, Jul 17, 2012 at 5:29 AM, David Blevins <[email protected]>wrote: > First, love the name :) > > On Jul 16, 2012, at 12:31 PM, Alex The Rocker wrote: > > > We are considering Apache TomEE+, but we are concerned by the lack of > clear > > update policy of Tomcat version in TomEE & TomEE+. > [..] > > it > > would be nice to have a clear statement on Apache TomEE/TomEE+ update > > policy with regard to the components it embeds (and not only Apache > Tomcat) > > ; so that users could decide whether or not they want to bed on this > "new" > > J2EE application server (yeah, we know it's J2EE with web profile). > > > > A commitment to update TomEE & TomEE+ when an Apache Tomcat fix of > security > > vulnerabilities within very short time (<2 weeks) would clearly be nice, > if > > possible. > > Thanks for the note. There is definitely room for these kinds of > considerations. > > There's been talk of keeping a branch just for upgrades and that could > easily help with this kind of thing. Releasing an active trunk on short > notice would be impossible, but a stable branch with nothing more than > upgrades would be far easier. > > Creating new builds with upgrades is very quick (minutes) and we can > easily have one up for public consumption with any upgrade in short order. > They're currently published daily: > > http://tomee.apache.org/builds.html > > What's there are trunk builds, so unstable by definition. > > Were there to be a stable codeline that contained only upgrades and had > builds also performed automatically every 24hrs, would that be enough? > > We could still release it of course, though a two week guarantee on that > would be harder; one is an automated process and one is very manual. > > > -David > >
