Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [microprofile-wg] [DISCUSSION] [BALLOT][PLAN REVIEW] MicroProfile Config 3.1 - Voting ends on June 11th
Thank you Jan for more information! Yes, the PR (https://github.com/eclipse/microprofile-config/pull/773) will be reverted as well. I will go through the current master branch to ensure mp parent 2.x is used, not 3.1.

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.

Hope this helps!

Thanks
Emily
On Wed, Jun 14, 2023 at 5:21 PM Jan Westerkamp <jan.westerkamp@xxxxxxx> wrote:
Hi Emily,

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.

Hope my explanation addresses your concern!
Thanks
Emily









On Tue, Jun 13, 2023 at 10:05 PM Jan Westerkamp <jan.westerkamp@xxxxxxx> wrote:
-1 (iJUG)

Why:

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:

 

    https://github.com/microprofile/microprofile-wg/pull/188

 

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


_______________________________________________
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


--
Thanks
Emily


_______________________________________________
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


--
Thanks
Emily

Back to the top