Tagging or Branching?

[Kevin Sutter]

Now that we're getting closer to having a MicroProfile 1.1 release, I'm curious about tagging or branching our current repos.

For example, we have the microprofile-conference and microprofile-samples repos that work with MicroProfile 1.0.  When MicroProfile 1.1 with Config 1.0 comes along, we want a version of these applications that will work with these new features.  Normally, we would tag or branch these repos when the new releases become finalized -- since the development of these features would have been done on the master branch as part of new development.  We would then tag/branch as MicroProfile 1.1 and master would then start on the next release (ie. 1.2-SNAPSHOT).

But, since we started with MicroProfile 1.0 in a different repo, if we start developing the application updates on master, then we've lost the ability for a customer to pull the version of the application that worked with MicroProfile 1.0.

First question, are we going to tag or branch?  Tagging is easier.  And, we could always branch later, if it's necessary for support.

Next question, should we go ahead and tag/branch our current microprofile-conference and microprofile-samples repos with MP 1.0 (or whatever we decide)?  This would allow us to modify these applications in prep for the Config 1.0 and MP 1.1 releases.

Next question, naming convention for these tags/branches.  According to the github suggestions, we should use some type of semantic versioning numbering prefaced by a v.  Something like v1.0, v1.1.2, etc.  We can also use some type of pre-release tags like v1.0-Beta.  Since we have separate repos for each of our deliverables, then this would probably work just fine.  On the other hand, with having separate repos, v1.0 in microprofile-conference may not immediately correlate to MicroProfile 1.0.  So, should we consider something like v1.0-MicroProfile or v1.0-MP?

Thanks, Kevin

[Ken Finnigan]

To be honest I'm not sure if this approach is workable.

Once MP 1.1 is released, it's not possible to update the conference or sample repos for each vendor implementation until that vendor implementation has a release that supports MP 1.1. For some that may be immediate, for others it could be a couple of months or more.

There may also be times where a vendor doesn't implement a particular MP version, which means their implementation in samples and conference isn't updatable for that release.

We may find that we don't ever tag or branch anything in samples and conference, but we have a README indicate which MP version each vendor implementation supports that is present in the projects.

Ken

--
You received this message because you are subscribed to the Google Groups "MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/56145c65-fdbb-43c6-bffc-7128cd7506ef%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Kevin Sutter]

Excellent point, Ken!  All I was thinking of were the APIs, but these applications depend on the implementations as well...  Doh!  You are right, these particular repos might be difficult to tag.

What about the other repos like microprofile-config or microprofile-bom?  Any input on the naming conventions?  If we avoid the application repos, then maybe just following the suggested vX.Y.Z naming convention is good?

--  Kevin

[Ken Finnigan]

I think for non example repos, ie. the features and BOM, it makes sense to stick with a tag of X.Y.Z

I don't think we need 'v' as a prefix

Ken