We plan to continue supporting v1 components even after we release Jaeger v2, at least for a year. During that period we need to enhance our release process such that both v1 and v2 artifacts are published, as well as make the corresponding changes to the documentation.
Proposed release process:
We will continue releasing v1 and v2 components from a single main branch of jaeger repository
Each release will have two tags, a continuation of the existing 1.x version tags, and a new series of 2.x versions.
The 2.x versions will initially have the form 2.0.0-rcN and we will keep incrementing N.
There will be just a single combined release on GitHub, with both versions in the title, e.g. 2.0.0-rc1/1.61.0
The binary artifacts for v2 will be uploaded as a separate set of archives, each will include only the jaeger binary
That means the schema / rollover scripts are still going to be 1.x - we could reconsider that and bundle them into 2.x too
[x] change build info determination to allow for dual versions
[x] implement ability to do a dry run of the release workflow
[x] skip binary signing in scripts/package-deploy.sh or define temporary key
[x] decide: should scripts receive versions as arguments or lookup the git tags directly?
[x] consider changing release workflow to manual trigger. It can ask for two versions, validate their syntax and that they do not exist (if they do exist, it would require an additional override flag)
[x] enable versioned release of jaeger v2 binary (we only release latest now)
[x] compute-tags.sh does not understand semver-rcN syntax
[x] package jaeger v2 binary as a separate release artifact (currently not included in scripts/package-deploy.sh)
[x] revisit the use of BRANCH variable
[x] revising build-binaries-*** Makefile targets, they sometimes include os-arch, sometimes just os, simetimes just arch - it's a mess -- #5924
[ ] figure out how publish release workflow will work with dual versions. Should it still run on release/published event or rather on tags?
New process documented in RELEASE.md. Because we need two tags in the repo, they have to be applied manually, not via GH Release, which can only create one tag.
[ ] The GH Release can still trigger the release workflow, right now it has to be triggered manually after the release is published (because it will try to upload artifacts to a release).
[x] figure out how release notes script will work with dual versions
[x] do we need dual version for the UI? -- continue using 1.x for now, once 2.x officially released switch UI version to 2.x, but still use a single version
We plan to continue supporting v1 components even after we release Jaeger v2, at least for a year. During that period we need to enhance our release process such that both v1 and v2 artifacts are published, as well as make the corresponding changes to the documentation.
Proposed release process:
mainbranch ofjaegerrepository2.0.0-rcNand we will keep incrementingN.2.0.0-rc1/1.61.0jaegerbinaryTasks:
scripts/package-deploy.shor define temporary keylatestnow)scripts/package-deploy.sh)build-binaries-***Makefile targets, they sometimes include os-arch, sometimes just os, simetimes just arch - it's a mess -- #5924release/publishedevent or rather on tags?RELEASE.md. Because we need two tags in the repo, they have to be applied manually, not via GH Release, which can only create one tag.