Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-community] Is backward incompatibility change allowed in Jakarta EE?
I believe that if JakartaEE is going to move at a faster pace than JavaEE then we might need to address backwards compatibility in a different way than JavaEE. There's always a risk that new functionality introduces some problems or unnecessary complexity. It's happened in JavaEE (e.g. JMS has a new simplified API to "fix" the old one). Faster releases only increase the probability. 

I propose that individual specs can have backwards incompatible releases provided that the incompatibility only affects new things in the previous releases that aren't yet in any umbrella JakartaEE spec.

For example, CDI 3.0 introduces new API. CDI 3.0 isn't yet part of any JakartaEE umbrella spec. A problem in the new API is discovered. CDI releases 4.0, which is backwards incompatible with 3.0. But the change only affects new API so CDI 4.0 is compatible with CDI 2.0. Then CDI 3.0 would be skipped from the umbrella and CDI 4.0 would target JakartaEE instead.

For that to work, it makes sense to have an incubation period between releasing individual specs and adding them to JakartaEE. For example, a new spec would wait 6 or 12 months before being included in JakartaEE. 

Once a new version of a spec is added to JakartaEE umbrella, it should remain backwards compatible or use proper deprecation that takes several releases to remove a feature. 

I know that individual specs would then sometimes introduce incompatibility without a warning but this is only limited to new functionality and thus has limited impact. 

Ondro


Dňa ut 18. 2. 2020, 23:21 Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> napísal(a):

Not sure why I get a special role. I’m just co-piloting the Jakarta EE 9 release 😊

 

I think we should adopt and then document a backwards compatibility and deprecation strategy. My preference is for a 3 phase strategy; deprecate; mark as optional; remove. Although it depends somewhat on the release cadence we agree.

 

Steve

 

From: jakarta.ee-community-bounces@xxxxxxxxxxx <jakarta.ee-community-bounces@xxxxxxxxxxx> On Behalf Of reza_rahman
Sent: 18 February 2020 21:37
To: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>
Subject: Re: [jakarta.ee-community] Is backward incompatibility change allowed in Jakarta EE?

 

I would agree with you certainly that should be status quo. I guess Kevin and Steve are the ones to provide a definitive answer (it was easier when the default choice was always Bill. Nowadays I am never sure any more).

 

Reza Rahman

Jakarta EE Ambassador, Author, Blogger, Speaker

 

Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.

 

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone

 

 

-------- Original message --------

From: Emily Jiang <emijiang6@xxxxxxxxxxxxxx>

Date: 2/18/20 4:20 PM (GMT-05:00)

To: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>

Subject: Re: [jakarta.ee-community] Is backward incompatibility change allowed in Jakarta EE?

 

When we discussed MicroProfile and Jakarta technical alignment, we assumed Jakarta EE does not allow backward incompatible changes. However, I have not seen it is noted anywhere, so I took the liberty to get some clarification.

It seems at least for Jakarta EE10, backward incompatible changes are not allowed. In the future, maybe a model of first deprecating and then removal can be adopted. Is this a fair assumption?

Emily

 

On Tue, Feb 18, 2020 at 3:55 PM reza_rahman <reza_rahman@xxxxxxxxx> wrote:

I rather agree. Backwards compatibility is probably a very common expectation from Jakarta EE given its Java EE pegidree. Suddenly changing that may scare people off. I think this is a topic that could be revisited once Jakarta EE establishes itself.

 

Stupid question: Is this a purely theoretical exercise or is there some urgent need to discuss this? Isn't this the flexibility MicroProfile is supposed to be providing anyway?

 

Reza Rahman

Jakarta EE Ambassador, Author, Blogger, Speaker

 

Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.

 

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone

 

-------- Original message --------

From: Rudy De Busscher <rdebusscher@xxxxxxxxx>

Date: 2/18/20 3:23 PM (GMT-05:00)

To: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>

Subject: Re: [jakarta.ee-community] Is backward incompatibility change allowed in Jakarta EE?

 

backward incompatible changes should be avoided, because Jakarta EE is just as Java EE about a stable set of APIs.

 

I guess that through the process of deprecation, one can 'schedule' the removal of a limited set of methods and classes in the long term.

 

On Tue, 18 Feb 2020 at 18:03, John Hogan <jhogan515@xxxxxxxxx> wrote:

IMO, backward compatibility is a critical value proposition that Java EE/Jakarta EE provides.  I don't see changing this as innovative, but rather the road to ruin.

 

A key pro for me is that your apps do not break with new versions of Jakarta EE.

 

On Tue, Feb 18, 2020 at 11:51 AM Emily Jiang <emijiang6@xxxxxxxxxxxxxx> wrote:

In Java EE time, backward incompatible changes are not allowed. I am wondering whether Jakarta EE still carries this requirement or to be a little of more innovative and then allows backward incompatible changes. There are cons/pros for either option. Thoughts?

 

p.s. namespace changes are one exceptional. I am looking at Jakarta EE10 and above releases.

--

Thanks
Emily

_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.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://www.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://www.eclipse.org/mailman/listinfo/jakarta.ee-community



--

Thanks
Emily

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

Back to the top