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?

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


Back to the top