| Re: [jakarta.ee-community] Which will be the initial Versioning Number for the first version of Jakarta EE |
-MrinalCouple of assumptions here: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.
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.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:
-MrinalThe 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.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.
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:
- 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.
- 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.
- 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-communit y
_______________________________________________ jakarta.ee-community mailing list jakarta.ee-community@eclipse.o rg To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jakarta.ee-communit y
_______________________________________________
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-communit y
_______________________________________________
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-communit y
_______________________________________________ jakarta.ee-community mailing list jakarta.ee-community@eclipse.o rg To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jakarta.ee-communit y
_______________________________________________
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-communit y