-
Notifications
You must be signed in to change notification settings - Fork 72
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Release Rest Client 2.0 #240
Comments
https://docs.google.com/document/d/16v3jVkcDzVz9BVU5aGEzPVbK-a8BIx7S1gbqToVUaLs/edit# |
Hi @pavolloffay - I have tentatively planned the MP Rest Client 2.0 release for January 28, 2020. |
That is too late it will not give OpenTracing spec enough time to release and make it to the umbrella spec. Could be the release done one week earlier - |
@pavolloffay January 28, not February. :-) My thought is that we would publish the release candidate on Jan 28 - then I think there should be a week to review before publishing the GA release. But that means that you would have a release in Maven Central on (or right after) Jan 28. |
It is too tight, I would prefer to have Rest Client release during week 20-26 in January. This gives us enough time to release and have backup days if something goes wrong. Note that we also have to give one week between RC and final release. |
That is pretty tight for me. It is still possible, but I can’t commit until I’ve looked closer - when I return from holiday. If that extra week is absolutely necessary, then we may need to discuss this at the platform level so that the platform leads can give us guidance. Thanks, and happy holidays! |
Are we talking MP REST Client 2.0 or 1.4? Only 1.4 can be considered for MP 3.3 in Feb |
@kenfinnigan I was planning to do this with MP Rest Client 2.0 - because the Java EE 7 -> Jakarta EE 8 dependency changes are a breaking change for standalone MP Rest Client users (anybody who uses MP Rest Client in an EE7 app), we had to call it 2.0. I had forgotten that the February release was not supposed to include breaking changes - that certainly causes a dilemma... I posted this on the Google Groups for wider consideration at: |
I might be missing something, but what about going from Java EE 7 to Jakarta EE 8 constitutes a breaking change? My understanding is that the Java EE 8 APIs are backward compatible with Java EE 7. |
I don't think EE8 APIs are 100% backward compatible with EE7, but I think most of it is. It's always possible that things would work, but once our dependencies change to EE8 we cannot guarantee that we will run in EE7 - nothing guards against us incidentally using a new EE8 API in the release that would cause a break to all EE7 users. Also, I had hoped to implement SSE in the rest client with issue #11 - SSEs are exclusively in EE8. This may not be a factor though since I'm running out of time... I think that the Maven dependency issues that you and Alasdair have been discussing on the Google Group thread may also be a breaking change - for example, if a user has specified Java EE 7 dependencies and MP Rest Client v.Next then they will either get a conflict or will end up with Jakarta EE 8 artifacts in their generated archive when they didn't before (which may also cause a classloading conflict at runtime). |
I thought Java EE 8 APIs had to be 100% backward compatible with Java EE 7? However, as the rest of MP is already aligned with Java EE 8 do we need to be concerned with compatibility with Java EE 7? |
You may be right, but I thought that there were some cases where it wasn't entirely backward compatible. Certainly there would be behavior differences - for example, JAX-RS 2.1 changes the order that entity providers are selected (using
Only for a very small niche of users. Anyone using the umbrella MP spec (or even MP Rest Client + 1 other MP spec) is fine - they should already be using the EE 8 APIs, so no possible change of behavior (at least nothing that I can think of) would occur with this change. The only users who would be affected are users of MP Rest Client standalone on Java EE 7 environments. So, it's a weird situation where from the MP umbrella spec perspective, there is no breaking changes at all. But from a standalone MP Rest Client perspective, there is at least the possibility of a breaking change. Given that explanation, do you think it makes sense for the MP umbrella to accept MP Rest Client 2.0 in the February release (since it won't break any umbrella users, only standalone users)? Ultimately, I think this is a good change. I'd like to move away from EE 7. |
It's going to need discussion in tomorrow's hangout as to how to handle this, as whichever way we go I think it will require some level of exception from the normal process |
I'm renaming this issue to be 1.4, and barring any major catastrophes, we should be able to release on January 20, 2020 for the MP 3.3 February release. As discussed in the community hangout, the Jakarta EE dependency issues will be resolved in MP Rest Client 2.0 as part of the MP 4.0 June release. |
As the update to Jakarta is not going to make it to MP 3.3 we are not going to release MP-OT for 3.3. Therefore we do not need the release of the rest-client for 3.3 release. |
Changed title to Release 2.0 since the next version will be 2.0. hi @andymc12 on July 22 component specs should be ready for MP 4.0 https://calendar.google.com/calendar/embed?src=gbnbc373ga40n0tvbl88nkc3r4%40group.calendar.google.com. Could you please release the final Rest Client 2.0 so we can consume it in MP-OpenTracing microprofile/microprofile-opentracing#179? |
No releases other than RC can be made due to the MicroProfile Working Group restrictions. So for the moment, MP-OpenTracing will need to use a RC. |
@andymc12 @kenfinnigan when do you plan to release the 2.0? The MP 4.0-RC1 is planned for November 10. The OpenTracing spec depends on MP-RestClient we have to update the dependency to 2.0 before cutting the release. |
Hi @pavolloffay - the release schedule is on the agenda for the MP live hangout (starting in 15 minutes). I should hopefully have a good answer for you after that. Please join if you can so that we discuss the schedule together. Thanks! |
2.0 is released - closing this issue |
OpenTracing depends on Rest Client. In OpenTracing we updated to Jakarta APIs, however to fully use Jakarta APIs we have to update Rest Client to 1.4 which updates to Jarkarta APIs microprofile/microprofile-opentracing#162 (comment)
Please release 1.4 with enough time for OpenTracing to be able to release before umbrella spec in February 2020 https://groups.google.com/forum/#!topic/microprofile/cDx5TlPFY1o
microprofile/microprofile#151
The text was updated successfully, but these errors were encountered: