[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] Transitioning Jakarta EE to the jakarta namespace

Hello folks,

The Brandon idea "@Deprecated" mixed with the "legacy profile"Â can be pretty helpful to have better backward compatibility due we can have a profile that allows gradually deprecate previous APIs versions, the profile ensure that we can have like a snapshot in which can start to work deprecating incrementally,
Âbut in legal terms that brandon mention will be violating the agreement?

Cheers

Carlos

On Tue, May 7, 2019 at 3:58 PM Brandon Heck <brandon.heck@xxxxxxxxx> wrote:
I apologize if this was captured in one of the options and I simply failed to interpret it correctly, but could the existing javax APIs be frozen and left in for at least one, or preferably two, releases of Jakarta EE? Can theÂ@Deprecated annotation be added without violating the agreement?ÂThe APIs could be copied over to the jakartaee package and new functionality and API changes can be made there. This would allow existing apps to continue to run on newer implementations without making disruptive changes while also allowing developers that want to move fast to utilize the new package and have access to the new functionality. Implementers could also have a large portion the javax APIs call through to the new jakartaee APIs.


On Mon, May 6, 2019 at 9:33 PM David Blevins <dblevins@xxxxxxxxxxxxx> wrote:
Great to hear from you!

> On May 6, 2019, at 7:22 PM, Hildeberto MendonÃa <me@xxxxxxxxxxxxxx> wrote:
>
> A way to add value is not increasing the maintenance cost and preserving backwards compatibility. I'm afraid Proposal 1 would break these two values.
> I would prefer Proposal 2 if jakarta worked as a wrapper around javax, preserving the same interfaces, reusing what is already there and innovating on the wrapper side.

Both proposals involve what you would call "a wrapper" and have the same basic backwards compatibility challenge of having to figure out how to make old apps run.

The primary place they differ is:

Â- do we break compatibility bit by bit over time in an as-needed basis
Â- do we break compatibility in one shot and get it over with

The primary question here is as a user how do you want to deal with migrating and potential compatibility issues:

Â- bit by bit over time
Â- in one shot

Knowing neither path frees you from having to absorb a backwards incompatible change and the solutions would be the same, which timeline is your preferred?


-David

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


--

Carlos Andres De La Rosa | Technical Architect

Mobile:Â+32465445631ÂÂ

Skype: carlosa.dlr