Skip to content
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

Closed
pavolloffay opened this issue Dec 11, 2019 · 21 comments
Closed

Release Rest Client 2.0 #240

pavolloffay opened this issue Dec 11, 2019 · 21 comments

Comments

@pavolloffay
Copy link

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

@pavolloffay
Copy link
Author

Considering a Feb 18th release, with component spec releases early Feb (between Feb 4th and 11th)

https://docs.google.com/document/d/16v3jVkcDzVz9BVU5aGEzPVbK-a8BIx7S1gbqToVUaLs/edit#

@pavolloffay
Copy link
Author

cc @kenfinnigan @andymc12

@andymc12
Copy link
Contributor

Hi @pavolloffay - I have tentatively planned the MP Rest Client 2.0 release for January 28, 2020.

@andymc12 andymc12 changed the title Release 1.4 Release Rest Client 2.0 Dec 19, 2019
@pavolloffay
Copy link
Author

pavolloffay commented Dec 19, 2019

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 - February 21 - January 21

@andymc12
Copy link
Contributor

@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.

@pavolloffay
Copy link
Author

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.

@andymc12
Copy link
Contributor

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!

@kenfinnigan
Copy link
Member

Are we talking MP REST Client 2.0 or 1.4?

Only 1.4 can be considered for MP 3.3 in Feb

@andymc12
Copy link
Contributor

andymc12 commented Jan 2, 2020

@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:
https://groups.google.com/d/msg/microprofile/cDx5TlPFY1o/zM06gHd4DQAJ

@kenfinnigan
Copy link
Member

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.

@andymc12
Copy link
Contributor

andymc12 commented Jan 4, 2020

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).

@kenfinnigan
Copy link
Member

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?

@andymc12
Copy link
Contributor

andymc12 commented Jan 6, 2020

I thought Java EE 8 APIs had to be 100% backward compatible 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 @Priority, adding support for JSON-B which might conflict with users using Jackson-based providers, etc.) and updating the process for exception handing when converting parameters, etc. - all minor changes granted.

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?

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.

@kenfinnigan
Copy link
Member

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

@andymc12 andymc12 changed the title Release Rest Client 2.0 Release Rest Client 1.4 Jan 14, 2020
@andymc12
Copy link
Contributor

andymc12 commented Jan 14, 2020

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.

@pavolloffay
Copy link
Author

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.

@pavolloffay pavolloffay changed the title Release Rest Client 1.4 Release Rest Client 2.0 Jul 1, 2020
@pavolloffay
Copy link
Author

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?

@rdebusscher
Copy link

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.

@pavolloffay
Copy link
Author

@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.

@andymc12
Copy link
Contributor

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!

@andymc12
Copy link
Contributor

andymc12 commented Jun 3, 2022

2.0 is released - closing this issue

@andymc12 andymc12 closed this as completed Jun 3, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants