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:
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?