v2.1.0 not reachable from the main branch

[farshidtz]

The v2.1.0 tag is not reachable from the main branches on projects with LTS. This is only relevant to Go projects.

The reason is that the v2.1.0 tag is associated to a commit that checks-in the the vendor directory inside the jakarta branch (e.g. edgexfoundry/edgex-go@b350bc7)

To verify:

$ git tag --help
...
       --merged [<commit>]
           Only list tags whose commits are reachable from the specified commit (HEAD if not specified).

       --no-merged [<commit>]
           Only list tags whose commits are not reachable from the specified commit (HEAD if not specified).
...

$ git clone https://github.com/edgexfoundry/edgex-go.git
$ git checkout main
$ git tag --merged | tail -n 15
v2.0.1-dev.96
v2.0.1-dev.97
v2.0.1-dev.98
v2.0.1-dev.99
v2.2.0-dev.1 <--------- jumped from 2.0.1-x to 2.2.0-x
v2.2.0-dev.10
v2.2.0-dev.11
v2.2.0-dev.2
v2.2.0-dev.3
v2.2.0-dev.4
v2.2.0-dev.5
v2.2.0-dev.6
v2.2.0-dev.7
v2.2.0-dev.8
v2.2.0-dev.9

$ git tag --no-merged 
0.6.0
0.6.1
0.7.0
0.7.1
v1.0.0
v1.0.1
v1.1.0
v1.3.1
v2.1.0 <--------- v2.1.0 not reachable from here

$ git log v2.1.0
not in main ---------> commit b350bc7f0b5978358426c58bec3f554618d1aae9 (tag: v2.1.0, origin/jakarta)
Author: edgex-jenkins <collab-it+edgex@linuxfoundation.org>
Date:   Wed Nov 17 23:34:23 2021 +0000

    ci(lts-release): LTS release v2.1.0 @0e57188
...

As a result, we faced few issues:

1. Prior to having the first v2.2.0-dev.X pre-release on main, the latest 2.1.0 snap builds were being published using a 2.0.1-dev.Y version.
2. Snapcraft was unable to fetch the tag for v2.1.0 when setting depth to 1. This may be a problem with snapcraft on how it handles tag and depth. We fixed that by fetching the branch instead (edgexfoundry/edgex-go@f650799 - see lines 816-818).
3. Cloning the repo with a limited depth will not fetch the tag. This could be a problem in CI systems or for a developer trying to checkout v2.1.0 from main without fetching the entire history (there are of course workarounds to fetch the branch, if the user is aware of the underlying situation). See below:

$ git clone https://github.com/edgexfoundry/edgex-go.git --depth=100
Cloning into 'edgex-go'...
remote: Enumerating objects: 2166, done.
remote: Counting objects: 100% (2166/2166), done.
remote: Compressing objects: 100% (1136/1136), done.
remote: Total 2166 (delta 1074), reused 1683 (delta 810), pack-reused 0
Receiving objects: 100% (2166/2166), 921.85 KiB | 3.12 MiB/s, done.
Resolving deltas: 100% (1074/1074), done.
$ cd edgex-go
$ git tag | tail -n 15
v2.0.1-dev.96
v2.0.1-dev.97
v2.0.1-dev.98
v2.0.1-dev.99
v2.2.0-dev.1 <------- There is no v2.1.0 tag here at all, merged or unmerged
v2.2.0-dev.10
v2.2.0-dev.11
v2.2.0-dev.2
v2.2.0-dev.3
v2.2.0-dev.4
v2.2.0-dev.5
v2.2.0-dev.6
v2.2.0-dev.7
v2.2.0-dev.8
v2.2.0-dev.9
$ git checkout v2.1.0
error: pathspec 'v2.1.0' did not match any file(s) known to git

[farshidtz]

This was briefly discussed in the DevOps call on Dec 2nd.

One proposal is to have two tags

• one prior to vendor check-in on main branch
• another after the check-in on the release branch

Consider LastCommit as the last commit before the release containing contributed code and vendor as the commit which checks-in the Go vendor directory:

What was done:

(main)    --- LastCommit 
(jakarta) --- LastCommit --- vendor (2.0.0)

Knowing that the tag is already there and removing or moving it (rewriting history) is bad, we can add a semver pre-release tag on the LastCommit.

(main)    --- LastCommit (2.0.0-vendor)
(jakarta) --- LastCommit (2.0.0-vendor) --- vendor (2.0.0)

Maybe in future we could consider adding the actual tag on the LastCommit and a new semver metadata tag on the commit that checks-in the vendor:

(main)    --- LastCommit (2.0.0)
(jakarta) --- LastCommit (2.0.0) --- vendor (2.0.0+vendor)

[tonyespy]

Just to add a little bit of historical context and why this issue was surprising to us when first discovered when building snaps for Jakarta.

Note - while this issue is meant to be more generic and applies to a number of our git repos, the following comments really just apply to edgex-go.

When the EdgeX project was launched, we adopted the LF's release process which required a mandatory branch to be created a few weeks before the final release, thus the early releases of EdgeX were tagged on a release branch. As Farshid points out, this includes the following non-patch releases:

• barcelona (0.6.0)
• california (0.7.0)
• edinburgh (1.0.0)
• fuji (1.1.0)

Note - I'm not sure what happened with the Dehli release, as I couldn't find a 0.8.0 | v0.8.0 tag in edgex-go.

As of the Geneva release, we changed our process and implemented a more commonly used practice of implementing a true "code freeze". This new process allowed us to simply tag the release on the master branch, which in turn meant we could create a release branch on-demand from the tag if/when the first patch release was approved by the TSC.

So the next three releases (again excluding "patch" releases) all were tagged on master (which eventually became main):

• geneva (v1.2.0)
• hanoi (v1.3.0)
• ireland (v2.0.0)

So as you can see, we used one tagging scheme for the first four major/minor releases, switched to a more commonly used scheme for the next three releases (include Ireland), and then reverted back to the original scheme (due to our approach to vendoring) for Jakarta.