Next MicroProfile release

[Kevin Sutter]

Hi,
In our bi-weekly hangout yesterday, we had a good discussion about our next releases of MicroProfile.  We're still all in agreement that the time-boxed releases are working out well.  To that end, we are proposing a MicroProfile 1.3 release in 4Q.  Due to the end of year holidays, I have set the release date for Friday, Dec 15.  Of course, we can adjust this as needed, but I wanted to clean up our governance page with better information.

https://projects.eclipse.org/projects/technology.microprofile/governance

We also discussed the proposed MicroProfile 2.0 release which would update our Java EE dependencies to Java EE 8.  Since this would be a major release and 4Q releases don't get the "hoopla" that other times of the year provide (thanks, David, for that reminder), we decided that this should be moved out to next year.  There is also a concern about having real implementations available that would support these new specs.  To that end, I moved this out to end of 1Q2018, but we can adjust this as needed.

Since we want to stick with quarterly releases, the 1Q2018 release may become a MicroProfile 1.4 and MicroProfile 2.0 might move to 2Q...  We'll have to see how things play out.

Back to MicroProfile 1.3...

We have three new components baking right now:
-  Open Tracing 1.0
-  Open API 1.0
-  Type-safe Rest Client 1.0

There may also be updates to the current specs that have been proposed due to feedback received at JavaOne and/or the recent MicroProfile 1.2 release.  Maybe a Metrics 1.1 or JWT 1.1, for example.

The point is that MicroProfile 1.3 will go with what's ready.  If a new or updated component wants to be on this train, the first thing to do is announce your intention with Release tag on our Governance page.  Just click on "Create Release..." and follow the prompts.  Note, you have more ability to edit the name and other things when you go into Edit mode on the Release.  So, whether you are creating Open API 1.0 or updating JWT 1.1, we need that release identified.  If you have problems or questions, ping me.

And, the other thing we need to do is to create corresponding "include me" Issues in the microprofile-bom component.  Something like what John has done for the Rest Client:
https://github.com/eclipse/microprofile-bom/issues/52

Hope this helps to keep our momentum going.  We made great progress at JavaOne with our MicroProfile 1.2 release.  Let's keep moving!

Thanks, Kevin

[John D. Ament]

I've gone ahead and created a Rest Client 1.0 release marked as a major release targeted to the same day as the 1.3 release.  I am committed to shipping something for the rest client as a 1.0 for the 1.3 release, whether it addresses all use cases is to be determined.  

John

[John D. Ament]

One question, because the process still isn't clear to me.

For Rest Client, we'll need to use one of the many tools that spin up "mock" servers for API call testing.  In the PR I have open I have proposed using Wiremock for that server, a personal favorite of mine.  With the eclipse dependency check process, I'm not sure this falls under a test dependency, since technically its shipped in the TCK which implementors need to use a test dependency, but we would ship as production code.

So what process do I follow to get Wiremock approved for use (assuming others agree with its use)?

Some of the other tools include Mock Server. 

[Emily Jiang]

John, 

Whether API or TCK brings the dependencies makes no difference to the approval process. You can raise a bugzilla (an example: http://dev.eclipse.org/ipzilla/show_bug.cgi?id=14119) to get the dependency approved.

Emily

[Kevin Sutter]

Just to clarify Emily's answer a bit...  There *is* a difference between getting approvals for software packaged with our APIs and/or TCKs and getting approvals for software used in our build and testing of our APIs and/or TCKs.  The software that is packaged with our artifacts goes through a bit more scrutiny from an IP review process than the build/test software.

So, depending on how Wiremock will be used and packaged by the Rest Client, that will determine how extensive of an IP review is required.  You could always go through the full CQ process per Emily's suggestion and just get the full approval from Eclipse.  This would allow us to use it either capacity.  But, if it's really only used as a test artifact, then you could wait and allow it to be processed as part of our normal release processing.

Thanks, Kevin

[Steve Millidge]

I would have a concern about pushing back 2.x release with the reason "There is also a concern about having real implementations available..." as this has the whiff of entering the domain of implementer politics. i.e. who has to have an implementation ready for a microprofile release to be given the go ahead, 1 implementer , 2 implementers a majority of implementers? 

2.0 could likely be shipped now as it is just a pom which updates the JavaEE versions and adds JSON-B along with all currently released Microprofile apis.

I agree for the reasons David mentioned that Q1 2018 would be a good date so let's put a stake in the ground and release on that date no matter whether there are any implementations ready.

Steve