Micro release process

[Andy McCright]

Hi All,

We ran out of time before discussing this topic on today's hangout, but I thought I would bring it up here to get some feedback before we discuss it next week.

The process for releasing major (e.g. 1.0 -> 2.0), minor (1.1 -> 1.2), and micro (1.0.0 -> 1.0.1) versions of a MicroProfile spec is defined here:

https://wiki.eclipse.org/MicroProfile/SpecRelease/Release#Major_or_Minor_or_Micro_Final_Releases

It is (IMO) a fairly heavyweight process involving a lot of paperwork, voting, reviews, etc. I can fully understand taking this time for major and minor releases, but it seems like overkill for micro releases.  In general, I would expect a micro release would only include fixing typos in the spec or javadoc text, or tweaking a TCK test case to be more in line with the spec/API.  

Would it be possible to change this process to allow for quicker and easier micro releases that still has some level of oversight?  Perhaps something like lazy consensus that we used prior to the formation of the WG?

Additionally, I may need some guidance on how to perform a micro release for MP GraphQL. It is an independent spec that has not had a major or minor release under the new WG. There is already a 1.0.3 spec released, but now we have made a TCK change which we would like to release. The total amount of code changes between 1.0.3 and our proposed 1.0.4 is less than the content of this paragraph, so it seems like a shame if we had to invest the time and effort of a full release for such a small change.

The MP GraphQL TCK change would enable a new player (Helidon) to certify, which is ultimately a win for the MP community.  If we need to use the heavyweight release process, could we perhaps just have Helidon exclude the test in question and claim certification on 1.0.3?

Thanks!

Andy

[Emily Jiang]

Hi Andy,

A similar issue on service release was discussed at Jakarta EE call. Kevin opened an issue with EF. The bottom line is that this requirement is mandated by the release process of Eclipse Foundation.

I suggest to use the issue Kevin opened to work with EF to see whether the process can be made more flexible.

In the meanwhile, I think there is an exception process we can follow:

Exceptions to this process may be granted only with Super-majority approval of the Specification Committee and approval of the Executive Director. All exceptions must be documented as part of the public record. Such documentation must include the exact change to the process, the case or conditions under which it applies, and the votes of each Specification Committee member.

Notwithstanding this exception process, no Specification Committee ballot period may be shorter than seven (7) days.

This exception process may not be used to override a Specification Committee member’s request to extend the ballot period.

Thoughts?

Thanks

Emily

[Andy McCright]

Thanks for the info and the link Emily.  I think it would be better to change the process rather than seek an exception for all micro/patch releases - the exception process is less work than the full release process, but there's no guarantee that it will be approved, so in the end a micro release might still have to go through the whole process.

This topic is queued up for the next community hangout.  I think the next step would be to determine what we can do to change the process.  Otherwise, I fear that projects will be discouraged from producing micro releases.

Thanks again,

Andy

[Kevin Sutter]

I agree, Andy, that the micro/service/patch release process must be lighter weight than the major or minor release process.  As you can see by the Issues and PRs that have been created, this was "clear as mud" from a Specification Process perspective.  At the end of our last Spec Committee call, it was determined that we need to clear this up at the EFSP level to at least allow the override at a derivative process (ie. the JESP).  Wayne (EMO) has the baton to attempt to move this forward with the EFSP.

One requirement that we all agree with is that a major and/or minor release needs to be successful before a micro/service release can be done.  This may be obvious.  But, we didn't want the situation where a component is processing a 1.1.1 release without formally performing a successful 1.1 release.

We also all agree that a micro/service release can not have any functional changes.  None.  This is to protect the IP flow agreements.  Only syntactic updates to the Spec, Javadoc, and/or TCK are allowed.  Any functional updates will require a new minor release.

Since MP must now adhere to the EFSP, we will need to follow the documented process.  At least for the near term.  I would definitely add your two cents worth to my Issue against the EFSP.  And, then file your exception with the MP Spec Committee (same as Steering Committee) so that you can make progress with your GraphQL micro/service release.  At a minimum, you will need to create an Eclipse Release record with information on what you are trying to deliver.  And, if we have to take that through a Spec Committee vote to release it, so be it.  At least with MP, we have a much smaller set of Specs than all of Jakarta EE...

Thanks,

Kevin

[Emily Jiang]

Based on what you said Kevin, I think in Andy's case, a formal process for this micro release needs to be followed as I realised MP GraphQL spec has not been through the process defined by MP WG. All of the copyright, licenses for javadoc etc needs to be updated based on the defined process. Therefore, I don't think an exception can be given as the previous MP GraphQL 1.0 release does not count as a  formally performed release.

Having that said, I strongly support a lighter weight process for service/bug releases. I will try to bring it up at Eclipse Foundation Architecture Council as well.

Thanks

Emily

[Kevin Sutter]

Andy,

I re-read your original post and one of your questions was regarding an update to the TCK for a micro/service release.  Although, technically, the TCK is considered part of the overall Specification (doc, api, and tck), we (Jakarta EE) have already done service releases for the TCK.  For example, in order to update the "exclude lists" for the TCKs, we have already created the 9.0.1 release for the TCK and we're working on a 9.0.2 release.

https://download.eclipse.org/jakartaee/platform/9/

I think this is a perfect example of why we can't have a heavy weight process for delivering these micro/service releases.  We have to continue to make progress with these TCKs in a timely manner.

-- Kevin

[Martin Stefanko]

Kevin,

just a clarification on "Only syntactic updates to the Spec, Javadoc, and/or TCK are allowed.  Any functional updates will require a new minor release." -- Does this mean that we can't include a bug fix that would change the code of the TCK test in a micro release to for instance accommodate some changes needed in a new implementation that wants to certify? I may be just reading it wrong.

Thanks,

Martin

[Andy McCright]

Kevin,

Thanks for the info - I added a comment with link to this thread to the EFSB issue https://github.com/EclipseFdn/EFSP/issues/29

Martin,

> just a clarification on "Only syntactic updates to the Spec, Javadoc, and/or TCK are allowed.  Any functional updates will require a new minor release." -- Does this mean that we can't include a bug fix that would change the code of the TCK test in a micro release to for instance accommodate some changes needed in a new implementation that wants to certify? I may be just reading it wrong.

Kevin is out until Tuesday, so I'll take a stab at clarifying, and he can correct me if I am mistaken.

My understanding from chatting with Kevin is that it would be possible to fix a bug in the TCK in a micro release.  For sure you could exclude challenged tests - Jakarta EE is already doing that in micro releases.  But I believe that it should also be possible to fix TCK bugs too - but there is probably a line somewhere that we cannot cross - for example, adding a new test or directly changing the intent of a test (i.e. changing assertTrue(something) to assertFalse(something)), etc. would likely require at least a minor release.

Emily,

> Based on what you said Kevin, I think in Andy's case, a formal process for this micro release needs to be followed as I realised MP GraphQL spec has not been through the process defined by MP WG. All of the copyright, licenses for javadoc etc needs to be updated based on the defined process. Therefore, I don't think an exception can be given as the previous MP GraphQL 1.0 release does not count as a  formally performed release.

Yes, I think this makes sense. So I think we would need to do the full process for MP GraphQL 1.0.4 but if the EFSP issue is resolved favorably, we might be able to perform a lighter-weight process for future micro releases. I'll discuss this more with the rest of the MP GraphQL developers at our next call and see whether we want to do a 1.0.4 release or if we would be better off waiting until 1.1 is ready for release.

As for MP Rest Client 2.0.1, I will plan to wait for resolution of EFSP 29 before taking any action.

Thanks!

Andy 

[Emily Jiang]

As mentioned previously, I brought up this issue in Eclipse Foundation Architecture Council with Wayne. Wayne is working on a new version of EFSP v1.3 and address this issue under EFSP 33, with a ETA of April 2021 Hopefully all Spec committees agree with the removing the review requirement for service releases.

Thanks

Emily