It’s also possible to switch to 7.1, 7.2 etc. If we have hotfix releases we are also free to use a 4th digit.
EE numbers will be 1 digit in the forseeable future. LieGrue, strub > Am 13.05.2015 um 17:29 schrieb David Blevins <[email protected]>: > > I see the +1s for version alignment and get the draw. Seems everyone has > tried it at least once -- the appeal is obvious. > > There will be some challenges. > > SLOW VERSIONS > > OpenEJB attempt to align versions: We've had this exact vote before to keep > OpenEJB aligned with the EJB version. In fact I was pro-alignment on that > debate. From 2006-2008 we tried to keep them aligned, but we ended up moving > faster than the EJB version and it got very awkward. > > Wildfly attempt to align versions: Wildfly started a 7 which matched Java EE > 7. They are now on version 8, which is understandable as EE 7 came out 2 > years ago and it will be another 2 years (or more) till Java EE 8 comes out. > That would be 4 years with the same major version. > > IRADIC VERSIONING > > We will go from 1.0 to 1.5 to 2.0 to 7.0 then we'll be someday be awkwardly > ahead of Java EE versions. In the process we'll look more immature than > mature. It won't show us being a stable community. > > COMMUNICATING > > Are we asking too much of the industry to say "we're not like the rest of the > world, for us 7.1 and 7.2 are is a major version change." > > What's going to happen the very first time someone goes to upgrade from a 7.2 > to say 7.3 and those are actually completely different servers at the same > level of a change from 2.x to 3.x. How many users will be confused or > mislead by that. > > We have to proceed knowing that many users will perceive us as unstable when > we change defaults and other things on "major" releases which are now > effectively the second digit. > > SHOWING PROGRESS > > With the 3.5 - 4 years between major releases, how exactly do we show and > communicate progress or innovation to the users with only changing the major > version once in 4 years? > > Are we happy only having a major release announcement once every four years? > > Major news outlets will not cover point releases. We have to proceed knowing > we are giving that up. > > Would be great if we could have a major announcement every 2 years at least. > We can't pretend that doing an 8.0 release then an 8.1 release 2 years later > will be understood by the world. > > EXCITEMENT > > How fun will it be to work on a server that you know in advance will only > change major versions twice in 7-8 years. > > - - - - - - - - - - - - > > The project became more successful when we changed from OpenEJB to TomEE > because we didn't have to continuously work against our labeling "I know > we're called 'EJB' but we actually have more". We fixed a perception issue > and we excelled. > > If we change the server every 2 years but our label changes only every 3.5 > years we'll be creating a similar communication/perception issue, "I know > what it looks like, but actually..." > > Do we want to answer this question over and over again for the next 8 years? > > What is harder to communicate: which TCK we pass or when there is major > change, minor change and bug fixes? > > > -David >
