Please, remember that the current main (with the Parent update to Jakarta 10), was targeting MP 7.0 (which requires the update).
There was nothing wrong in there. The plan was to release MP 7.0 by now, which unfortunately got delayed. If that was the case (as planned when the update was merged, it was ok). It is perfectly fine to change timelines, versions and release plans, but please, lets not ignore the context.
Did not got the current process in my
mind regarding this to require a Minor Release.
As a consequence, a Patch (or regarding
the process wording Service) Release of MP Config 3.0.2 (to 3.0.4,
as 3.0.3 was released already) for an MP 6.0.1 would require
another cherry picking branch.
Best,
Jan
Am 14.06.23 um 19:48 schrieb Emily
Jiang via microprofile-wg:
As for the minor changes not patch release, according to
the Spec TCK process,
The only time tests may be added to a TCK are in a major
or minor
release.
MP Config 3.1 will have TCKs additions and update, so a
minor release is required.
p.s. The same TCK requirement applies to Jakarta EE as
well. The intent is that patch release should not prevent the
certified runtime from passing the certification.
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
_______________________________________________ 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
