You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by David Blevins <da...@gmail.com> on 2015/05/13 17:29:29 UTC

Java EE version Alignment Troubles

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


Re: Java EE version Alignment Troubles

Posted by Mark Struberg <st...@yahoo.de>.
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 <da...@gmail.com>:
> 
> 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
> 


Re: Java EE version Alignment Troubles

Posted by Romain Manni-Bucau <rm...@gmail.com>.
2015-05-13 17:29 GMT+02:00 David Blevins <da...@gmail.com>:

> 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.
>
>
was my point


> 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?
>
>

Finally I think nobody cares about versioning excepted people not knowing
what's java excepted a dance so we did a choice and we just need to move
forward now IMO.


>
> -David
>
>