Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [microprofile-wg] [BALLOT] MicroProfile 7.0 Release Proposal 1. Vote by June 12, 2023

-1 (Microsoft).

While we understand this vote will likely succeed, we feel we should point out the following weaknesses in this strategy, somewhat as a caveat for all stakeholders, customers and users:

* We believe the core value proposition for open specifications is compatibility. This strategy weakens compatibility as various implementers of the same MicroProfile release will support various versions of Jakarta EE and Java SE. This means applications are less portable across implementations.

* This strategy opens up the possibility that while a MicroProfile release does not indicate a breaking change, the application will break anyway because it may also essentially be forced to upgrade to breaking versions of Jakarta EE or Java SE for a given implementation release. This places an additional burden on users to check all technology versions that an implementation supports themselves and reduces confidence that the MicroProfile release version scheme clearly signals the intended nature of an upgrade, including all key transitive dependencies.

* Changing the Jakarta EE dependency from 'compile' to 'provided' essentially places a burden on users to explicitly add a Jakarta EE dependency themselves. This is very strange for a technology set that has many direct dependencies of Jakarta EE APIs and probably will be unexpected for most users. The MicroProfile version in which this change is made will likely immediately cause breaking builds for most applications that users must mitigate themselves.

* This strategy will very likely mean fewer rather than more frequent MicroProfile releases, reducing the marketing perception of MicroProfile as a nimble technology that builds upon other key Java specifications and standards.

On 6/13/2023 3:17 PM, Jan Westerkamp wrote:
-1 (iJUG)

Why:

While some aspects (as mentioned in the discussion and also referenced in proposal 5, as the provided Jakarta EE dependency and component spec to component spec relation) are fine, it covers also cases (allowing multiple Major Jakarta EE releases as a base for MP), where I strongly suggest NOT to do it that way, as it will end up even more in  dependency hell - directly!

This will reduce maintainability and violates a clean contract to the users.

While making things simpler for MP implementation vendors (small group), from my point of view it creates technical debt that complicates users (should be the largest group affected here) live and also that of contributors/committers (a little bit bigger than the vendors employees) - is this the right way to go for the future?

Best,

Jan

Am 07.06.23 um 17:49 schrieb John Clingan:

Ballot text:

"Resolved, the MicroProfile Steering Committee approves the MicroProfile 7.0 proposal 1 to support a minimum Jakarta EE Version"

The proposal 1 text is pasted below from the MicroProfile 7 release proposal document.

This is the vote thread. Feedback/discussion, if needed, should be given in a separate thread with the subject of [DISCUSSION][Proposal 1][MP 7.0].

A Steering Committee Representatives vote is requested. Please respond with +1 (positive), 0 (abstain), or -1 (reject). Any feedback that you can provide to support your vote will be appreciated.
This ballot runs for seven days, so it ends on June 12th, 2023. The ballot requires a Simple-majority positive vote of the Steering Committee members. There is no veto. Community input and Community votes are welcomed. However, only the votes delivered by Steering Committee Representatives will be counted.


----------

Proposal 1: MicroProfile releases support a minimum Jakarta EE versions 

  • Given a MicroProfile release, specify a range of Jakarta EE dependencies, past and future. Possibly along the lines of “depends on Jakarta EE Core version y or above”.


  • The minimum Jakarta EE  version would be specified in the MicroProfile umbrella specification like it currently is in the component specifications.

    • The minimum Jakarta EE Core Profile version would be 10 for MicroProfile 7

  • The Jakarta EE Core Profile API jar will be marked provided in the pom.xml as they are for the component specifications.

  • MP Implementations must pass the Jakarta EE TCK for the version and profile they implement.

  • It is expected that MP implementations and community will actively be participating in new EE releases, passing both TCKs and surfacing compatibility issues eagerly.

    • Whenever a new EE release happens, MP needs to review whether the current release works with the new EE release. If not, a new MP release needs to be done as soon as possible


  • If there are backwards compatibility issues that would prevent an implementation from passing the respective TCKs, those kinds of issues would need to be addressed through the specification process (i.e. a major, minor or service release).

    • In the event proposal 1 is not possible because an implementation is not able to pass the TCK of both Jakarta EE.latest and MicroProfile, this would be addressed through a MicroProfile spec update (essentially proposal 3).

  • MP Certification Requests  (CCRs) must specify the exact Jakarta EE version and profile was implemented and passed in their certification results.


    

 Q&A

  • How open-ended is this supposed to be? What if a Jakarta EE release breaks backwards compatibility? Who determines this without actually re-running the TCK?

    • Implementations need to test it out before certifying against a higher of Jakarta EE

  • What is the TCK requirement for this?

    • Must pass Jakarta EE y+ TCKs and MicroProfile x TCKs

    • Some minor Jakarta EE releases could have backward incompatible changes by mistake. How do we account for that?

      • It means this Jakarta EE version can not work with the particular MP release. A new MP release have to be done to bring up the minimum version of Jakarta EE.

    • If a MicroProfile component uses CDI 4.0, some aspects required must be CDI 4.0 or higher.


  • Cons:

    • Compromise portability as various implementations can support various Jakarta EE versions

  • Pros:

    • Allows implementations to align with Jakarta EE versions as they best see fit

    • Requires less frequent MicroProfile releases


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




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

Back to the top