Thread-topic: [EXTERNAL] Re: [rest-dev] Branches and Preparing for Jakarta REST 5.0
It has been deprecated, I'll say pseudo deprecated, in the documentation [1] since 3.1. We, or maybe just I, wanted to formally deprecate the types in Jakarta REST 4.0. However, I was told there needs to be a replacement before something can be deprecated,
and CDI can't be a replacement until decisions are made for things like the Client API where we may be running outside of a container.
I would personally be a -1 for just removing it. That would completely break backwards compatibility. Not just for applications, but for the libraries applications use as well.
From: rest-dev <rest-dev-bounces@xxxxxxxxxxx> on behalf of Arjan Tijms via rest-dev <rest-dev@xxxxxxxxxxx> Sent: Tuesday, October 7, 2025 2:37 AM To: Jared Anderson <jhanders@xxxxxxxxxx> Cc: Arjan Tijms <arjan.tijms@xxxxxxxxxxx>; rest-dev@xxxxxxxxxxx <rest-dev@xxxxxxxxxxx> Subject: [EXTERNAL] Re: [rest-dev] Branches and Preparing for Jakarta REST 5.0
Hi, On Mon, 6 Oct 2025 at 22: 03, Jared Anderson <jhanders@ us. ibm. com> wrote: I thought we always deprecated function in a release before removing it. That one is a clear rule indeed. @Conext has NOT been marked deprecated yet which is
I thought we always deprecated function in a release before removing it.
That one is a clear rule indeed.
@Conext has NOT been marked deprecated yet which is why it needs to be done in the next REST release so that it can be removed in the following one.
We should have just deprecated it for the last EE release, but alas.
The rule is not, perhaps unfortunately, about the REST release, but about the EE release. To be included in the platform we need to deprecate it for inclusion in EE 12, and then for EE 13 we can remove it. If we meanwhile introduce minor REST updates,
it doesn't "count" (as-in, the rule would not apply).
Jakarta REST itself has no rule that says we need to deprecate first and then remove it in a version after that.
Kind regards,
Arjan Tijms
Do you have examples where we removed function without deprecating it first?
Thanks,
Jared Anderson
On Mon, 2025-10-06 at 21:46 +0200, Arjan Tijms via rest-dev wrote:
On Mon, 6 Oct 2025 at 14: 57, Jim Krueger via rest-dev <rest-dev@ eclipse. org> wrote: I agree that we've been discussing this for years. However, I believe it is required that functionality be marked as "Deprecated" with an
On Mon, 6 Oct 2025 at 14:57, Jim Krueger via rest-dev <rest-dev@xxxxxxxxxxx> wrote:
I agree that we've been discussing this for years. However, I believe it is required that functionality be marked as "Deprecated" with an alternative implementation for a release (point release is fine) prior to removal. If I'm wrong on this
requirement I would be fine with removing @Context in EE12.
I'm not really sure where that is written. If it IS indeed a rule, we have violated it many, many times before.
Kind regards,
Arjan Tijms
On Fri, Oct 3, 2025 at 3:57 PM Markus KARG via rest-dev <rest-dev@xxxxxxxxxxx> wrote:
In the end, *eventually* we need to do it some fine day, so why not in EE12? What is any better in EE13?
We're postponing this since years...
Am 03.10.2025 um 20:27 schrieb Jim Krueger via rest-dev:
Question: The addition of the alternative implementation for injection and the deprecation of @Context is certainly a significant change so perhaps going with 5.0 is the consensus and I'm fine with that. But technically we could instead use
a 4.1 point release for EE12 and save the full version change for the removal of @Context in EE13. Thoughts? We could make this change easily before the M1 release, but after that we are stuck with the full 5.0 release I think.
On Thu, Oct 2, 2025 at 4:31 AM James Perkins via rest-dev <rest-dev@xxxxxxxxxxx> wrote:
You're right. I definitely remember this now 🙂 Sorry I dropped the ball there.
This is something I can likely look at, but probably not until next week. I'm on PTO Friday and Monday, but back Tuesday.
Welcome in the Jungle! This is exactly what I wanted to clarify many months back when I reached out to you, and the result was that nobody responded. :-( Seems we need to dive into each single commit to find out what is what. :-( -Markus Am
Welcome in the Jungle! This is exactly what I wanted to clarify many months back when I reached out to you, and the result was that nobody responded. :-(
Seems we need to dive into each single commit to find out what is what. :-(
-Markus
Am 30.09.2025 um 23:00 schrieb James Perkins via rest-dev:
Hello All,
We're aiming to have an M1 for Jakarta EE 12 by 2025-10-15 which is just a couple weeks away, see [1].
Looking at the branches I'm a bit confused on what branch we should be working on. There is a release-5.0 branch which is quite different from main. Both contain changes the other one does not and I don't know which one we should be using. There was a PR raised
[2] to address some of the requirements for an M1 release However, some of things have already been done in the release-5.0 branch, for example removing the security manager [3].
I think the first thing we need to do is determine which branch we should use and stick with that branch. My personal preference would be main and merge what we need from release-5.0 into main, then delete the release-5.0 branch.
After that, we can start moving forward with any other changes that are needed.
