Conversation
As a source of entire Envoy version number. Will use this file in envoy
main repo as well.
By this change, document version string will be changed in development
version:
from: "1.6.0-data-plane-api-${GIT_SHA}"
to: "1.6.0.dev-data-plane-api-${GIT_SHA}"
And in release version, for example, in v1.6.0 release:
from: "1.6.0-tag-v1.6.0"
to: "tag-v1.6.0"
The significant change is dropping the first version number string like
"1.6.0-" in the release version document.
Signed-off-by: Taiki Ono <taiks.4559@gmail.com>
VERSION
Outdated
| @@ -0,0 +1 @@ | |||
| 1.6.0.dev | |||
There was a problem hiding this comment.
Any reason to do .dev here? In theory I agree it sounds good, but we will need to override it for tagged builds. Personally, I would skip it for now so it closely matches what we are already doing. We can consider adding the tag to the version string Envoy side when we do the final version work there?
There was a problem hiding this comment.
Adding dev is for indicating this is not release version, discussing envoyproxy/envoy#2276 (comment). (excuse me but it should be -dev not .dev.)
For tagged builds, my suggested release workflow is: we will rewrite this VERSION file with release versions (like 1.6.0), then commit and add a git tag. After the release task is done, we will rewrite this file with next development version (like 1.7.0-dev?).
Currently, I think this workflow is simpler than adding the tag (git tag?) string to the version string in Envoy side when we do the final version work. But since I'm not familier the current release workflow, any comments and suggestions are very welcome. I want to improve the release workflow as well.
Another suggestion is: rename the VERSION file to RELEASE or RELEASE_VERSION. The content should be version number + an indicator. For example, the content will be 1.5.0+ for current version.
There was a problem hiding this comment.
I agree that it's useful to have a distinction between release version and the HEAD between releases. I think the scheme in this PR could work if, when we tag, we do a commit first to put a non -dev version in place, tag, then a following commit. So, it's two extra commits, which doesn't seem too bad if we only release every few months.
There was a problem hiding this comment.
OK SGTM as long as we understand the multiple commit implications this will have:
- Commit final version here (or RC if we start doing that)
- Commit in envoy repo using SHA of commit in this repo.
- Tag.
- Commit here again for next dev version.
There was a problem hiding this comment.
Yeah, it's exactly the one I expected.
Signed-off-by: Taiki Ono <taiks.4559@gmail.com>
mattklein123
left a comment
There was a problem hiding this comment.
thank you for working on this!
For envoyproxy/envoy#2276 (comment). Use this file in envoy main repo as well.