thanks for the update, it addresses
some of my concerns, but not all of them:
There is another merged PR
(https://github.com/eclipse/microprofile-config/pull/773) that
updated MP Parent to 3.1, that need to be reverted then to - or
there need to be a cherry picking on a new branch, when these are
kept and targeting a Major Release of MP Config.
But still the Release Plan sounds for
me to be a MP Config 3.0.4 Patch Release and not a MP Config 3.1
Minor Release (and the first would be required for a MP 6.0.1
Patch Release).
And MP Parent 3.1 is released already
without the recent security issues addressed, so at minimum a
3.1.1 or 3.2 will be needed to fix them - I updated the document
to use 3.x instead of 3.1.
Looks like Roberto had the same idea,
that I shared in the last meetings to decouple MP Parent from the
Jakarta EE Release to prevent maintaining multiple versions - but
this will be a breaking change in MP Parent.
The obvious solution to only have one
MP Parent version in one MP release is another option - also a
braking change for most of the component specs and the umbrella
spec.
In general, this shows for me the
problems with the current release strategy including MP (7.0)
Proposal 1 and "compiling low, running high".
Shortcuts hurting back!
And as my live is to short for
volunteering in doing the maintenance for this - this should be
done by the people who voted for such an approach! ;-)
I am happy to see, that at least you
are willing to do that. :-)
While still be affected, I hope we can
improve this in the future and prevent work that can be prevented.
Release management should be simple and
fast, resulting in a high release cadence again and not in Major
Releases (or Maintenance/Patch/Service Releases) only.
Users like Minor Releases, as updating
to them do (or should) not hurt, while the other types are
required to fix things and/or handle the breaking changes.
Thanks
Jan
Am 13.06.23 um 23:52 schrieb Emily
Jiang via microprofile-wg:
Hi Jan,
Thanks for providing your feedback!
I think your comment was referring to this PR made to the master
branch. I was surprised such a substantial PR was merged
without being reviewed nor discussed. I commented after the fact. The
better solution is to fix the 2.x branch of parent pom.xml
instead of updating the whole Jakarta EE dependencies.
In our recent MP calls, we discussed which parent pom.xml
the other specs should rely on. It was documented here. Therefore, the upgrade of
the parent pom to 3.1 (this PR) should be reverted.
Moving towards Jakarta EE 10 without the need of using
Jakarta EE 10 was against the principle we set up:
"compiling low, running high". By the way, the upgrading
parent pom to depend on Jakarta EE 10 Core Profile is NOT
part of the release plan.
This is a very tricky decision for me, where I am
unsure to vote between 0 and -1. I decided for -1 only,
because it violates Semantic Versioning, but with a
version 3.1 based on MP Parent 3.1+ it tries to fix an
issue (MP Config 3.0.2 for MP 6.0 was based on Jakarta
EE 9.1, as MP Config 3.0.3 too), that should have been
fixed for the last release - with a Major Release of the
spec...
The Release Plan notes the following, that sounds for
me like a Patch Release only:
The goal of this release is to improve the TCKs so that
they can work well with CDI Lite.
* Improve TCKs to enable they work well with CDI Lite
* Some minor spec clarification
The version that was part of the MP 6.0 release
should work well with CDI Lite already.
Minor spec clarifications sounds for me fixing
something - not enhancing or breaking it.
When I look at recent commits, some dependencies got
a Minor Release update - so fixing it with a Minor
Release sounds reasonable. But when only non-public APIs
are updated (internal dependencies), this could have
been done with a Patch Release.
But updating to MP Parent 3.1 is a (necessary)
breaking change for me - only coming too late. So this
is handled as a fix now?
I really appreciate this fix in general!
But on my opinion this is an example on violating
semver results in violating semver...
Which brings me to: Why we do not simply agree on
being compliant to semver?
I hope we can fix this in the future.
Thanks & Best,
Jan
PS: Another question would be, how we will fix this for
a MP 6.0.1 Patch Release? Add MP Config 3.1 for it or
create a MP Config 3.0.4, with will be based on MP
Parent 3.x?
Hello dependency hell...
Am 06.06.23 um 10:39 schrieb Emily Jiang via
microprofile-wg:
To
approve and ratify the Plan Review of the
MicroProfile Config 3.1 Specification, 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.
The
MicroProfile Specification Process requires
the Specification Committee and the Community
to provide feedback during the approval
process using the relevant documents:
This
ballot runs for seven days, so it ends on June
11th, 2023. The ballot requires a
Super-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.
--
Thank
you
Emily Jiang on
behalf of MicroProfile Steering Committee