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

[Alasdair Nottingham <alasdair.nottingham@xxxxxxxxx>]

Based on your clarification I agree that I misinterpreted your assumptions, although I think saying it was a gross misinterpretation is a stretch. I understood your first assumption to be that implementations support 1 and only 1 version of the spec, and on the second I took too much stress on direct rather than correlation so read it as saying that their major version was in lock step, which I now understand wasn’t your intent.

On the substantive point here though I think we have diametrically opposed view points. Some responses below

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

I think you have grossly misinterpreted my assumptions, or may be, I did not articulate them appropriately.

On Tue, May 1, 2018 at 5:25 AM, Alasdair Nottingham <alasdair.nottingham@xxxxxxxxx> wrote:

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. 

Almost all major Java EE implementations provide backward compatibility with at least one previous Java EE version. But that's not the point here.
 

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. 

Refer to http://www.oracle.com/technetwork/java/javaee/overview/compatibility-jsp-136984.html I am talking about direct correlation between app server major versions and Java EE versions which is clearly specified in the compatibility list

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.

In case of Java EE, the implementations(app server versions) haven't been far from the specification versions if you look at the compatibility list above. In most cases (though not all), an app server major version upgrade is due to a underlying Java EE specification version increment. I hope you are not suggesting that the app server vendors would be free to skip specific Jakarta EE specifications and choose to implement whatever specification version suits them for their next major release?
 

While I don’t know if I was suggesting this I absolutely believe that a Jakarta EE implementation must be able to choose whether to implement a specific spec version or not. While the Jakarta EE community may have a view on this, and would likely wish all versions to be implemented. I think it is a stretch to far to insist that to implement one version you must implement all prior versions.

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.

I know many consumers who are using unsupported community editions of app servers in production. They are happy to stay on the bleeding-edge of technology innovation.  I am only speaking for consumers who pay for reliability and support. I believe both type of consumers are essential to sustain innovation.

If all major versions of the Jakarta EE specs are released with equal importance and the implementors (app server vendors) are allowed to choose their own LTS versions, then this would create chaos and impact portability of applications from one LTS version of one provider to another LTS version of another provider. For example, if vendor A chooses to support Jakarta EE 9 implementation as LTS and another vendor B chooses Jakarta EE 8 implementation as LTS then it would be chaotic for a consumer to migrate their application from vendor A to B assuming they want to avail long-term-support post migration.

I don’t agree this is chaos, I think this is how a free market behaves. The implication of your statement would be that the Jakarta EE community decides on the service lifecycle and any implementation of the standard has to follow it and I think that is unreasonable.  I take this interpretation because even if there were an LTS and non-LTS if vendor A and vendor B can choose different lifecycles for those two then you would get back to the chaos you are concerned about.

On the other hand, if Jakarta EE specifies that v8 is an LTS version of the spec which implies that all app server vendors who implement v8 would have to support it for a longer term then it would be seamless (at least theoretically) for the consumer to migrate across any Jakarta EE v8 certified/compatible app server implementation and still avail long-term-support post migration.

Today the Java EE standard makes no statement about how long a Java EE version should be supported for, and it is down to the Java EE implementations to decide how long their implementation will be supported for. Each community can make a decision based on what is right for their user base. For commercial products that can also be a decision based on what best allows an implementation to compete with other commercial implementations. It essentially allows the support lifecycle to be a competitive differentiator. I don’t think a lack of a statement from a standard has inhibited this and I don’t think it’ll cause it in the future either.

-Mrinal

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