MicroProfile Config 2.0 Specification Review

[Emily-Jiang]

Specification issue template

When creating a specification project release review, create an issue in the MicroProfile-WG repository repo with the content defined as follows.

• Specification name and version
• Add the label Release Review
• Naming conventions for artifacts:
  • Specification PDF in the form of microprofile-project-spec-version.pdf
  • Specification HTML in the form of microprofile-project-spec-version.html
  • project is the microprofile specification short project name (config, health, ...)
  • version is the two digit x.y version of the specification

• The Nexus Staging links (orgeclipsemicroprofile-NNNN where NNNN is the staging repository id) (eg, https://oss.sonatype.org/content/repositories/orgeclipsemicroprofile-NNNN/org/eclipse/microprofile/config/) which contain all the binaries and relevant documentation:
  • Staging Repo
  • Spec PDF
  • Spec HTML
  • Javadoc
  • API Jar
  • TCK Jar

• A link in the Eclipse downloads sections is still available for specs and apidocs:
  • https://download.eclipse.org/microprofile/staging/microprofile-config-2.0/
  • An apidocs directory containing the javadoc associated with the API jar.

• Summary that a Compatible Implementation is complete, passes the TCK, and that the TCK includes sufficient coverage of the specification:
  • Compatible Certification Request

• Release Review
  • Follow governance process and create/update release record
    • Component Release Record
  • Email to PMC
  • Start release review by emailing EMO (Track the bug issue created by EMO after the email)
  • send microprofile-wg for voting

[radcortez]

+1

[radcortez]

/cc @jclingan @ederks85 @emecas

[Emily-Jiang]

Received +1 from PMC

Gunnar Wagenknecht [email protected] via eclipse.org | Gunnar Wagenknecht [email protected] via eclipse.org | Wed, Nov 18, 7:00 PM (1 day ago)
+1
Gunnar Wagenknecht [email protected] via eclipse.org

[Emily-Jiang]

https://bugs.eclipse.org/bugs/show_bug.cgi?id=568938

[radcortez]

https://bugs.eclipse.org/bugs/show_bug.cgi?id=568938

Can you add the link into the description, so it gets more visibility?

[kwsutter]

+1
I have reviewed the materials for this Config 2.0 release and all looks good. I will initiate the ballot review shortly.

[jclingan]

+1

[aeiras]

We forgot to include the final step, the Result Ballot notification after the initiated ballot is sent.
can you add the step to Metrics? https://docs.google.com/document/d/1wISp-yRzQZNOHULNekxxg1U18be3v-3CRUswklcpmr8/edit

Thank YOU! the general template needs to be adjusted as well. :)

[TetianaFTV]

+1 for Jelastic

[kwsutter]

Making a similar comment that I did on the Metrics #15 and Health #14 Issues... We need the Compatible Implementation that is used to verify the CCR to be more "permanent". There is a reference to SmallRye Config 2.0. Is this available in Maven or some permanent download location? A link would be good, if that's the case. Otherwise, we should create the SmallRye Config 2.0 artifact, store it, and provide a link. Thanks.

[radcortez]

Hey @kwsutter. It is available as a commit in the repo:
smallrye/smallrye-config@679c438

The issue here is somehow the same you have with dependent specs. We can't really do a release of the implementation without having the API publicly available. Once the API is out, we cut a release from the same codebase but without the staging repo reference and publish it in Maven Central. The link can then be replaced by the permanent binary in Central. Is this acceptable?

[kwsutter]

Hey @kwsutter. It is available as a commit in the repo:
smallrye/smallrye-config@679c438

The issue here is somehow the same you have with dependent specs. We can't really do a release of the implementation without having the API publicly available. Once the API is out, we cut a release from the same codebase but without the staging repo reference and publish it in Maven Central. The link can then be replaced by the permanent binary in Central. Is this acceptable?

@radcortez, the commit tag by itself is not sufficient. This would still require someone to download the exact code and build it in the exact same way in order to produce the binary. As time goes on, these processes will get muddled and the building will become more difficult.

Any Compatible Implementation needs to have a long life. It could be a Milestone driver, or a Release Candidate driver, or even a Snapshot driver -- as long as the binary has some repository where it will live and not accidentally get deleted. The best location is Maven. But, other long-lived download repos will also suffice.

I agree that it's a chicken-and-egg problem. We struggle with this at Jakarta as well. But, we need to have a long-lived CI that can be used at a later time to verify the compatibility. As an example, Jakarta EE 9 used Glassfish 6.0-RC2 as the CI. Some of the embedded implementations used by Glassfish had not finalized their versions yet. As soon as all of these are completed, then Glassfish v6.0 (final) will be used to re-certify as the CI. A new CCR will be filed and the data for the Jakarta EE 9 CI will be updated with the new information (added to, not replaced).

[radcortez]

Ok, updated the CCR with a RC release available in Central.

[Emily-Jiang]

I double checked the released and confirmed the release used the staged Config 2.0 api (see here) and passed the TCK.

[radcortez]

This is now in Maven Central: https://repo1.maven.org/maven2/org/eclipse/microprofile/config/microprofile-config-api/2.0/