|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.
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.
jakarta.ee-community mailing listjakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit