Definition of "Done" for a release

[Heiko Braun]

Can someone briefly outline what's necessary to release a project under the eclipse umbrella? I.e. IP policies, artefacts, artefact location, etc. 

Heiko

[Ondro Mihályi]

Hi Heiko,

I'll outline what we did for config, maybe Emily and Mark can add to it if I missed something.

1. Formally, it's necessary to do the following within Eclipse before a final version can be released

 - create a release in the Eclipse project site: https://projects.eclipse.org/projects/technology.microprofile

      - you have to be logged in, then you'll see "Create a new release" in the sidebar on the right

      - Kevin suggested that Type B of IP diligence is enough for feature releases and Type A should be selected for umbrella MP releases

 - generate IP log in the same Eclipse project site - link "Generate IP log" in the sidebar

     - IP log should be linked to the release you created

     - when IP log is generated, it will schedule an IP review for Eclipse fnd. They usually do IP reviews 1st and 3rd Wednesday each month

     - IP log covers all MicroProfile repositories, it's not possible to do a review of a single repository (if multiple releases are schedule around the same time, Eclipse probably joins all IP reviews into one)

     - wait for Eclipse to do the IP review, afterwards, artifacts can be released, no further checks are done by Eclipse

2. make sure the code in the repositories follows our project guidelines: https://wiki.eclipse.org/MicroProfile/ContributingGuidelines

 - Eclipse requires license headers and notice file (should be also inside distributed binary JAR files)

 - artifact and package naming (these are our internal guidelines to have consistency among features, but it's not enforced by Eclipse)

3. Eclipse requires creating milestone and candidate releases before a final release (requires is a strong word, it's not enforced but strongly suggested)

 - the consensus is that at least 1 candidate release should happen before final one

 - current MP Config procedure is that all artifacts are deployed to the Eclipse Maven Repository, except the final one, which is deployed to the Maven Central. In the future, maybe all artifacts will go to Central but deploying to Central isn't automated while deploying to Eclipse repo is

 - to deploy to Eclipse repo, create a Jenkins job in our Jenkins at https://ci.eclipse.org/microprofile/ (or copy existing job from another feature)

 - to deploy to maven central, it's necessary to 

                  1. generate sources and javadoc artifacts for all JAR artifacts

                  2. sign all artifacts with a GPG signature, even sources and javadocs (I'm using my own GPG key)

                  3. deploy manually from command line using a Sonatype account with access to the org.eclipse.microprofile namespace (see https://issues.sonatype.org/browse/OSSRH-32787)

--Ondro

[Heiko Braun]

Thanks Ondro, that's exactly what I was looking for. 

Heiko

[Emily Jiang]

+1 On Ondro's summary! Ondro, can you document this in our wiki for future reference?

Emily

[Ondro Mihályi]

For now, I added link to this thread into the wiki: https://wiki.eclipse.org/MicroProfile/SpecRelease

If I have more time, I'll improve it and to the wiki directly.

--Ondro

[John D. Ament]

I think we should add one additional critical piece for the DoD - confirmation that someone's actually implemented it, or at least started and not hitting any issues.  Last thing I think we want is that we publish a spec that you can't actually use.

[Ondro Mihályi]

I agree, John, although there's no way to enforce this.

We agreed that a spec won't deliver any RI. With Config, we had a sample implementation by Mark Struberg that passed most if not all test in the TCK - it was the only sensible way to test the TCK itself. And I recommend doing the same for all specifications. Having a sample impl isn't the same as a RI, because the sample impl isn't part of the delivery and doesn't have to be supported and even doesn't have to pass all TCK tests.

It's also very useful to announce the first release candidate ASAP and loudly announce it so that implementers are encouraged to work with it and report any problems or questions soon. Based on the experience from config, I recommend announcing the first RC a month or more before planned final release, to give enough time for implementers. With config, we underestimated this a bit, and although we were pretty loud about RCs and the first RC was released about a month before the final version, we still got a valid feedback after the final version was released. Fortunately, it was nothing serious, but if we rushed a bit more and shortened the period between the first RC and final, we would probably regret it.

--Ondro

[sst...@redhat.com]

I think we will need to have separate API/spec releases from TCK releases. What I had suggested in another thread was a time-box period after the release of the API/spec over which implementations can pass the TCK and allow it to be fleshed in the context of an implementation.