Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [] Which will be the initial Versioning Number for the first version of Jakarta EE

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.


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:

— 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,
_______________________________________________ mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

_______________________________________________ mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

_______________________________________________ mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top