No stupid question, only stupid answers. Apache ID = apache committer ID You can just say No and enter in an anonymous mode.
As soon as you validate it, we receive a patch to commit for you. @Romain, no need to follow Tomcat, was just to clarify things in my opinion and check their versioning to inspire ourself. But we are all free to do whatever we want. Jean-Louis 2012/12/30 Alex The Rocker <alex.m3...@gmail.com> > Okay, now time for a stupid question : I'm asked to enter an Apache ID, how > can I register one? (the ID which I use for JIRA doesn't work here) > > > On Sun, Dec 30, 2012 at 11:01 PM, Jean-Louis MONTEIRO <jeano...@gmail.com > >wrote: > > > That sounds pretty similar to Tomcat. > > If we can adapt a bit to make things even clearer I'm all for it. > > > > Whatever the next version will be, yes we can create a page and push our > > versioning thoughts and Java EE mapping. > > Would you like to start pushing your understanding as you proposed > > previously and how you would get them proposed? > > > > Just created a new page and committed it. > > http://openejb.staging.apache.org/tomee-version-policies.html > > > > You can edit it and push a patch directly on the website using the top > > right blue pen. > > You don't need to be a committer. > > > > Thanks in advance > > JLouis > > > > > > > > > > 2012/12/30 Alex The Rocker <alex.m3...@gmail.com> > > > > > Jean-Louis: > > > > > > I wasn't very clear, sorry for that, but I think you got the idea :) > > > If I understand well your proposal of TomEE versioning, it would be > > x.y.z, > > > with x=1 for Java EE 6 ; and y moving when there are "new features" and > > "z" > > > moving for fixes. > > > > > > Why not, but this is a little bit different from Tomcat's x.y.z : > > > - it seems that Tomcat x version is correlated to a Java Servlet & JSP > > > specification, so TomEE's x meaning a given Java EE version, with x=1 > <=> > > > Java EE 6 is consistent. > > > - For the middle version number y, I have been so much used to Tomcat > > 6.0.x > > > that I wasn't considering features (other than Java EE version) changes > > > - For the last version number z, your proposal for TomEE (fixes) seems > to > > > be consistent with Tomcat's > > > > > > So it seems that I need to ask our certification team to adapt a little > > bit > > > our TomEE support policy, with a statement looking like this: our > product > > > is supported with Apache TomEE+ 1.5.x, x=>1 or with TomEE+ 1.6.z, y>=6. > > > > > > Now I have a request for you Jean-Louis: could your proposal for > version > > be > > > written somewhere in TomEE's internet side, including the major version > > > mapping to Java EE release, like this: > > > TomEE 1.x.y => Java EE 6 > > > TomEE 2.x.y => Java EE 7 > > > and the meaning of x & y (features & fixes) ? > > > > > > If you need a JIRA for this, then I can open it. > > > > > > Thanks, > > > Alex > > > > > > > > > > > > > > > > > > > > > On Sun, Dec 30, 2012 at 10:34 PM, Jean-Louis MONTEIRO < > > jeano...@gmail.com > > > >wrote: > > > > > > > Hi Alex, > > > > > > > > You are all welcome to share your needs and what you expect (and also > > to > > > > help if you can ;-)). > > > > > > > > IMO, TomEE 1.x.y is only Java EE 6 dedicated. > > > > The work on Java EE 7 will start Q2 2013 I guess or a bit after and > it > > > > should produce the 2.x.y of TomEE. > > > > > > > > Java EE 8, dunno for the moment, maybe a TomEE 3.x.y > > > > > > > > > > > > Back to 1.x.y, the third digit is usually for maintenance (bugfix and > > > > improvements). The second one is for new features and significant > > > changes. > > > > Between 1.0.x and 1.5.0, we had a discussion all together and agreed > > that > > > > there were lot of new feature and improvements (see release notes > where > > > all > > > > should be clearer). We wanted to emphasis that huge work and decided > to > > > > jump in the version. > > > > > > > > I'm not proposing to jump again, I just wanted to know what community > > and > > > > users have in mind and like to see in next release to decide what > > numbers > > > > are better. > > > > > > > > If 1.5.2 is a new maintenance release and does not contain any big > new > > > > feature, I'm all ok to use that numbers. > > > > I'm not aware of Tomcat producing a new version since our last > release, > > > but > > > > the 1.5.2 could embedded the new release if available as well as > other > > > > dependency upgrades. I have in mind at least CXF and maybe OpenJPA. > > > > > > > > Is it clearer? > > > > If I badly interpreted your thoughts, apologize and lemme know. > > > > > > > > Jean-Louis > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2012/12/30 Alex The Rocker <alex.m3...@gmail.com> > > > > > > > > > Jean-Louis: > > > > > > > > > > This is a very serious topic for my company: we're releasing a > > product > > > > > which we document that it is supported with Apache TomEE+ 1.5.x, > > x=>1. > > > > The > > > > > rationale for allowing our customers to use an higher "fix" version > > is > > > to > > > > > benefit from Apache Tomcat security fixes. > > > > > > > > > > When our product was based on Apache Tomcat instead of TomEE we had > > the > > > > > same type of support policy : for example we wrote that we > supported > > > > Apache > > > > > Tomcat 7.0x, x=>23. > > > > > > > > > > I am very concerned by a TomEE 1.6.0 version which could put an end > > to > > > > the > > > > > 1.5.x series. > > > > > > > > > > Would it be possible for Apache TomEE team to stick to Apache > Tomcat > > > > > version conventions (too late for the middle number which could > have > > > > stayed > > > > > to '0', so we should be at version 1.0.3 instead of 1.5.1) ? > > > > > > > > > > Otherwise, if a 1.6.0 version is actually planned (for Java EE 8 > > alpha > > > > > support, why not), then please keep 1.5.x series actives for a > > (long). > > > > > > > > > > Thanks, > > > > > Alex. > > > > > > > > > > > > > > > > > > > > On Sat, Dec 29, 2012 at 11:44 PM, Jean-Louis MONTEIRO < > > > > jeano...@gmail.com > > > > > >wrote: > > > > > > > > > > > Hi guys, > > > > > > > > > > > > That are some painful bugs in 1.5.1. > > > > > > They are fixed in the trunk. > > > > > > > > > > > > So the question here is: what are the plans for next releases? > > > > > > > > > > > > We have basically 2 options: > > > > > > 1. try to push a new 1.5.2 by February or so > > > > > > 2. push a 1.6.0 > > > > > > > > > > > > We don't have so much new features for now, so I'm quite sure, we > > > will > > > > > get > > > > > > a 1.5.2 out. > > > > > > Thoughts are welcome. > > > > > > > > > > > > Another question is what to put in? > > > > > > As said previously, there are number of bugs fixed in trunk. > > > > > > Anything else you wanna get in? > > > > > > Any work (improvement, bugfixes, dependency updates, etc)? > > > > > > > > > > > > > > > > > > -- > > > > > > Jean-Louis > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Jean-Louis > > > > > > > > > > > > > > > -- > > Jean-Louis > > > -- Jean-Louis
