[
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"
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
The minimum Jakarta EE version would be specified in the MicroProfile umbrella specification like it currently is in the component specifications.
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.
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).
MP Certification Requests (CCRs) must specify the exact Jakarta EE version and profile was implemented and passed in their certification results.
Q&A
_______________________________________________
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