Ivar,
I am also +1 with your plan. That should satisfy the platform team, and satisfy the industry’s desire for faster releases.
Markus, do you want to adjust the date for the 3.1 release to roughly match the 3.0 release?
I agree, and believe is actually a better option, to release 3.0 with only the package changes and 3.1 shortly after. So +1 on that proposal.
— Santiago Ivar, thanks for sharing your opinion. I'm +1 with all you say. The one year comes from Andy's recent changes to the JAX-RS roadmap. -Markus Thanks for your proposal. I would pref if we discuss first before changing the WIKI to not confuse readers. As the platform project is not our superior (only the spec committee and EE4J PMC are), and as the SE Bootstrap is backwards compatible (it is an *optional* feature), I do not see that we MUST shift SE Bootstrap to 3.1. As it is already existing since 1,5 years in Jersey, so our downstreams EE 9 platform and Eclipse GlassFish both have no efforts including it, and customers have no drawbacks. Hence I would vote for including it in 3.0 already unless either the spec committee or the EE4J PMC officially forbid that.
The PMC does not have a view on this matter. It is up to the spec project to choose which version of the individual components they include in the platform. As long as there isn't anything jeopardizing the delivery plan of Jakarta EE 9, I see no reason why they should object to adding the optional features since they're already implemented by Jersey. What you _could_ do is to release a 3.0 without the optional features and a 3.1 with the optional features directly after and leave it to the platform project which they pick for Jakarta EE 9. If it is within the required release dates in order to make it to the release, I see no reason why they would choose 3.0 over 3.1... Regarding the time frame, users expect to get things more early and more often. 3.0 (zero new features!) in Q2 and 3.1 (more or less one single feature) in ONE YEAR FROM OW is much too late, much too less. It is "one year lost" from the user's view angle. We have to commit to more in less time (again, it is not IBM, Oracle and Red Hat doing that committment and work, it is this project and *all* its committers, so there are more hands than possible seen when drafting the plan).
I don't see where you get the one year from. You can release as often as you like and can manage... My counterproposal is: Reverting your changes in the WIKI and then adjust *only* the version numbers. Hence, keep the original plan but just with a different name. What do others think? -Markus Hi All, I updated the JAX-RS Roadmap page [1] to reflect the requirements of the Jakarta EE 9 release plan [2]. (1) Updating the major versions (i.e. from 2.2 to 3.0) - as I understand it, this is a hard requirement for EE 9. (2) Removing "additional content" from the 3.0 (previously 2.2) release. As I understand it, the EE9 release plan requires no changes to the EE 8 APIs other than the package rename (and pruning, where relevant). I interpret this as we will need to remove the SE bootstrap feature from the 3.0 release, so I put that into the 3.1 release. Please review these changes - feedback appreciated. _______________________________________________
jaxrs-dev mailing list
jaxrs-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jaxrs-dev
-- Ivar Grimstad Jakarta EE Developer Advocate | Eclipse Foundation, Inc. Eclipse Foundation: The Platform for Open Innovation and Collaboration
jaxrs-dev mailing list
jaxrs-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jaxrs-dev
_______________________________________________ jaxrs-dev mailing list jaxrs-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jaxrs-dev
|
