Re: [jakarta.ee-community] Which will be the initial Versioning Number f

[Alasdair Nottingham <alasdair.nottingham@xxxxxxxxx>]

I don’t agree with your assumptions. 

Assumption 1) I know of at least one Java EE implementation that supports multiple Java EE spec versions. 

Assumption 2) None of the following Java EE implementations have a direct correlation with major versions and Java EE specification versions: Wildfly, Geronimo, Liberty, TomEE, WebSphere, Payara, WebLogic. 

Assumption 3) While I think this is a fair assumption I think you are leading it to a place where the specifications dictates how implementations support their users, which I think should be a question for the implementation.

I fear that the adoption of LTS and non-LTS variants based on the OpenJDK precedent will effectively slow innovation on a platform that needs innovation that people can use. In this way I think OpenJDK and Jakarta EE are very different.   There will be many users that will choose not to use a Jakarta EE release because it isn’t an LTS release, even there are implementations prepared to do so. If there are LTS Jakarta EE releases every 3 years that is a slower rate of effective innovation for those users for whom long term support is important.

As Bill says I think the question of support for a release needs to be a question not for the specification, but for the implementation. I think the question of how many releases and how often is an important one to discuss, but I don’t think it should be combined with support lifecycles.

Alasdair

On Apr 30, 2018, at 7:47 PM, Mrinal Kanti <mrinal.kanti@xxxxxxxxx> wrote:

There is also a third assumption which I missed in my earlier mail:

3) At any given time an app server vendor can effectively support 2-3 major versions of their app servers. This coupled with assumption #2 earlier would mean that frequent major releases of Jakarta EE specifications would result in shorter support life-cycle of major version of app servers or force the app server vendors to support more than 3 major versions at any given point of time.

-Mrinal

On Tue, May 1, 2018 at 4:57 AM, Mrinal Kanti <mrinal.kanti@xxxxxxxxx> wrote:

Couple of assumptions here:
1) The specifications drive the implementations and they have a one-to-one correlation for any single provider (or one-to-many if we consider multiple providers).
2) Traditionally, app server major versions had direct correlations with Java EE specification versions.

I am suggesting that frequent release versions of Jakarta EE specs should not introduce features that mandate upgrade of Java SE versions as it would not be convenient for consumers to upgrade Java SE versions frequently for reasons stated earlier. Any such feature should be introduced in longer life-cycles which are typical for app servers major versions. The usage of the terms long-term-support(LTS) and feature-release(FR) may be prevalent in product implementations; I am just trying to provide a similar analogy in case of Jakarta EE specifications which would inherently drive the implementations (and versions) of app servers as per assumption #2.

We also need to factor in the various licensing and support pricing models for app servers that would have an impact on consumers. For periodic subscriptions agnostic of app server versions, the regular Jakarta EE/app server FR release versions should not be an issue from cost perspective. But for those who purchased support only for a major version (say, as part of license) this would cause them to renew their license/support subscription more often in the absence of LTS versions.

-Mrinal

On Tue, May 1, 2018 at 3:56 AM, Bill Shannon <bill.shannon@xxxxxxxxxx> wrote:

Remember that we're talking about the version number of the specification, not the version number of any particular implementation.  Eclipse GlassFish might have a Long Term Support release, but does it make sense for a specification to have a Long Term Support release?  Would that then require every product implementing that specification to follow a similar support model?

Unlike Java SE and OpenJDK, there will many different products with completely different implementations of the Jakarta EE specification.

Peter Richardson wrote on 04/30/18 03:00 PM:

I second the notion of LTS versions if those were not already in the plan. I thought the Oracle JDK was also planning to have LTS versions so aligning with those may be logical.

LTS releases are critical when working with customers that have extensive testing, security, and accreditation requirements. Java EE just won't be an option for these customers if there are not versions that will receive security patches etc for long periods of time.

-Peter Richardson-

On Mon, Apr 30, 2018 at 5:53 PM, Mrinal Kanti <mrinal.kanti@xxxxxxxxx> wrote:

I would suggest that Jakarta EE version numbers are NOT the same as Java SE version numbers even though both Java SE and Jakarta EE may now have regular release cycles. This is owing to the fact that Jakarta EE versions may be required to support older versions of Java SE and keeping the version numbers same may create confusion that end-users must upgrade to the corresponding Java SE version as well.

Though, internally we may establish guidelines that Jakarta EE X should be compatible with, say, Java SE versions Y-2 and supported till Y+2 where X is the current Jakarta EE version and Y is the current Java SE version. There are a lot of third-party framework and libraries which are developed outside the Jakarta EE/EE4J umbrella and hence have different release cycles (if any). This should give end-user sufficient time to upgrade those libraries/frameworks or find a suitable replacement.

The other option may be to have Long-Term-Support versions which really mandate a minimum Java SE version upgrade while having several Feature-Releases at regular intervals which may incorporate more recent versions of Java SE. The LTS version life-cycle should align with the support life-cycle windows that most app server vendors usually have for any given version of their servers. Changing the support life-cycle window for app servers would definitely have downstream impact on application developers.

-Mrinal

On Tue, May 1, 2018 at 2:37 AM, Bill Shannon <bill.shannon@xxxxxxxxxx> wrote:

I think we've been using "8" or "8.0" as an informal way of indicating that it will be compatible with Java EE 8, but I think we should make an explicit decision about how to do version numbering for Jakarta EE once we have the right group in place to make that decision.  I'm not clear on whether that would be the Steering Committee, the Specification Committee, or the Jakarta EE Platform project.

Once we're clear on who gets to make the decision, I see three obvious choices:

1. Continue the Java EE version numbering approach with Jakarta EE X being based on Java SE X, for all values of X.  With the new rapid release cycles of Java SE, that might mean skipping some version numbers to allow Jakarta EE to stay in sync with Java SE.
   
2. Start with Jakarta EE 8 and increment the version number for each release, making a separate and explicit decision as to what version of Java SE to base each release on.
3. Since so much of Jakarta EE is a break from the past, start over with Jakarta EE 1, incrementing the version number for each release.

Independently of the above is the decision of whether or not to use minor version numbers, and if so for what purpose.

Dmitry Kornilov wrote on 04/30/18 03:53 AM:

8.0

— Dmitry

On 30 Apr 2018, at 12:28, Alexander Salvanos <salvanos@xxxxxx> wrote:

Hi everybody,

 

So far, we had agreed that the first version of Jakarta EE should technologically be conform to the state of Java EE 8 technologies and no further additions should be added. Is this still the plan? And if we so, what version number should we use for this initial version of Jakarta EE? Currently, I was thinking it will be Jakarta 1.0. But, in the email conversion Jakarta 8.0 appeared as well.

 

Best Regards,

Alex

 

 

_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community

_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community

_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community

_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community

_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community

_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community

_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community