Discuss separating TCK releases from spec/apis

[Scott Stark]

I would like to revisit a topic that has been touched on in the past, namely updating the release process to support separate release cycles for TCKs. Since we don't have RIs for our specs, it is natural for the TCK to evolve as different implementations come online and issues come up. I also brought up the notion of having the initial release of a spec TCK trail the release of the spec/api by a time boxed amount so that as many implementation as possible can take a look at, and give feedback on the TCK. Let's discuss if this makes sense, and if it does, how it can be accomplished.

[Kevin Sutter]

Hi Scott,
Would you be envisioning a separate repo for the TCK?  Given our current release build process, that would probably be the cleanest.  I suppose there might be a way to have our general release process work on a per sub-directory pattern, but I think it would get kind of ugly and confusing.

Actually, as I consider this a bit further, this would require a separate component/module as well.  So, we would need corresponding microprofile-*-tck components for each microprofile-* component.  At least that's the way the current build process works.

I do agree that the TCK probably needs to evolve at a different pace than the spec and api.  I know that Heiko Rupp did this with a 1.0.1 update to Metrics for the TCK.  We should get input from him on what hurdles he hit with this experience.  This would still show the close relationship between the TCK and the corresponding spec/api.  That is, could we just use the third digit for spinning new versions of the TCK?

Regardless of how we decide to allow the TCK to grow independent of the spec/api, I would still like to see an initial cut of the TCK with each release of the spec/api.  Even new specs and apis.  I think that initial effort has definitely solidified the spec and api.  The TCK may not be 100% done, but it is a good start and something to work with immediately.

My initial thoughts...
-- Kevin

[Scott Stark]

We probably could have it in the same repo, but I think it simplifies things to have it separate. What I would like to see on the initial release of the spec/api is the equivalent of a public final draft release of the TCK, and then follow up with the final release matching the spec/api in some time box, say 30-60 days.

[Emily Jiang]

Originally I advocated for a separate repo, one for api/spec while one for tck. I do see one issue: how to clearly identify which version of tck matches which version of api/spec. One solution is to keep the same major and minor version so that we know these version of artifacts match. I now wonder whether we can update the release process to just release the sub directories without releasing the full tree. If it is possible, it is the best.

Emily

[Scott Stark]

Right, only the patch level should be changing for each independent release of a tck.

There is a release plugin that does exactly what would be ideal, but I have never used it:

http://danielflower.github.io/multi-module-maven-release-plugin/index.html

I'll look around for other examples, but it seems like Kevin might be suggesting that a separate repo would be required for independent releases?

[Kevin Sutter]

Hi Scott,
I was suggesting separate repos based off the current release processing for MicroProfile.  I don't think you've had the luxury of using John's revamped release process yet, but it's pretty nice.  We have a single set of scripts that can be used for any of the component or umbrella releases.  We can use the same process for both our early RCx drivers, as well as our final "1.0" releases.  It also interacts directly with sonatype to get the artifacts properly staged and ready for release. 

From what I can tell with this release process, separate repos would be required if we didn't want to modify anything.  If somebody can modify this release process to separate the tck releases from the spec/api without requiring new repos, then I'm interested.  I just don't want to throw away what John has already done.  It is really pretty slick.

--  Kevin

[John D. Ament]

Kevin,

The current release process just calls mvn release:prepare release:perform.  Technically, it would only be trivial changes to support the multimodule release plugin.  I think if its something you guys want to explore, just fork the Jenkinsfile and tweak it to see if it works.

Many of the processes we all follow are all backed by older SVN behaviors.  In SVN, it was common to have multiple roots so we wrote code that dealt with that behavior.  The git structure has historically been a single repo == a single releaseable artifact.  Many people are changing that mindset, and if it works elsewhere it may work for MicroProfile.

John

[Kevin Sutter]

Thanks, John.  I took a quick look at the multi module release plugin.  There are a few minor differences between that and the official release plugin, but they should be doable.  The one bigger difference is that the updated poms are not committed back to the repo.  We'd also have to decide whether to limit this functionality to just the tck module (that's my vote anyway).  And, what numbering scheme to use (I like the third digit idea) to tie back to the spec/api version.  And, just some testing to check everything out...

Scott, do you have any cycles to experiment a bit and see if this would work?

Thanks, Kevin

[Scott Stark]

I'll look into it within the next couple of weeks and report back.

[Kevin Sutter]

Thanks, Scott.  If I have some cycles, I will experiment as well.  It doesn't look too difficult to use this alternate plugin, but it will affect our current processing slightly.

-- Kevin

[Scott Stark]

So I have been trying to update the microprofile-jwt-auth to use the new release process, but I'm not sure what all needs to change. I have tried to sync the poms with the changes that are described in this:

https://github.com/eclipse/microprofile-metrics/issues/173

but when I run the release ci step, it is failing to push the updated poms back. From the build logs, what is this error about not being able to read the username? The changes I'm testing are in in the release-test branch of the https://github.com/eclipse/microprofile-jwt-auth repo.

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.5.3:prepare (default-cli) on project microprofile-jwt-auth-parent: Unable to commit files
[ERROR] Provider message:
[ERROR] The git-push command failed.
[ERROR] Command output:
[ERROR] fatal: could not read Username for 'https://github.com': No such device or address
[ERROR] -> [Help 1]
[ERROR] 

[Mark Struberg]

Please excuse if I missed some details in the long thread.

I don't think we need any special release process.

The idea is to just create a branch for the TCK-only release. It's just a loose idea for now...

So e.g. if you have mp-jwt-1.2 and don't want to update any wording nor api nor spec, then you create a branch mp-jwt-tck-1.2.1

in this branch you remove all the modules you don't need (api + spec). And just leave the tck module. 

There you cherry pick over the desired changes from master. 

And then you can do a normal release.

Would that work?

LieGrue,

strub

[Scott Stark]

That would work, but it would not fit into the CI pipeline that would allow any project to push a TCK module change, and then just be able to kickoff the release pipeline to release just the TCK. I have updated the https://ci.eclipse.org/microprofile/job/Test%20Releases/ pipeline to allow one to choose between a Full or TCK release to verify that one could run alternative types of release builds in the release pipeline. That does work, but  I have been testing out the multi-module-maven-release-plugin and it has some quirks that I have so far have not been able to workaround. First is that it is using json info stuck in git tags using the [-m message] option to store a major.minor version + a buildNumber. We would have to tag using this convention or use the multi-module-maven-release-plugin for both full and tck releases.

The bigger problem is that the multi-module-maven-release-plugin is searching the commit tree for each module to see if there have been any commits past the commit associated with the module tag. This generally identifies that there are unreleased changes as our master branch is not a static branch post the previous release. Changes for the next release are typically being accumulated.

At this point I can see options:

1. Do manually releases as needed for the TCK as suggested by Mark.

2. Look into a fork of the maven-release-plugin that supports just releasing one subproject. No idea the scope of that effort as of yet.

3. Look into a fork of the multi-module-maven-release-plugin that would suppress the search of the git history for changes and simply verify that parent/api/spec artifacts for a given major.minor exist, and only release the tck major.minor.patch+1 version. This does not seem like much work, but the issue of tagging conventions is a problem.

At this point I'm wanting to take a quick look at determining the scope of option 2, and if that is non-trival, probably just documenting the process for option 1 is the best immediate step forward.

[Scott Stark]

Hacking the plugins doesn't seem worth it. I have a procedure that seems to work that uses Mark's branch suggestion, and then uses the https://ci.eclipse.org/microprofile/ release pipeline with a TCK release type to do the build and push to maven central. I'm writing up the procedure and will post it once I have run through it a couple more times.

[Mark Struberg]

Hi Scott!

Thanks for driving this. Did the trick work out?

I know it will always be a trade off between having to maintain 2 repos (and keeping them in sync), and having 1 which has 2 parts which are most times (but not always) in sync.

LieGrue,

strub