[ 
https://issues.apache.org/jira/browse/YUNIKORN-1004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17480261#comment-17480261
 ] 

Craig Condit commented on YUNIKORN-1004:
----------------------------------------

This has worked very well for the 0.12.2 RCs. In RC3, we had to update the 
k8shim, but none of the other modules, and we were able to build successfully 
using tags of v0.12.2-1 for all the modules and v0.12.2-3 for k8shim. 
Post-release we will retag v0.12.2 for consistency. I think this is a good 
pattern moving forward.

> Investigate tagging in GIT and the interaction with go modules
> --------------------------------------------------------------
>
>                 Key: YUNIKORN-1004
>                 URL: https://issues.apache.org/jira/browse/YUNIKORN-1004
>             Project: Apache YuniKorn
>          Issue Type: Improvement
>          Components: release
>            Reporter: Chenya Zhang
>            Assignee: Chenya Zhang
>            Priority: Major
>
> Experiment different ways to tag in GIT and its interaction with go modules.
> Discussed with [~wilfreds] offline, as soon as we tag a release that tag is 
> fixed and tracked from a go mod point. It cannot be changed. It creates a 
> problem for a release candidate: it needs a special tag and that tag cannot 
> be the real release tag due to the voting. For example, we can have something 
> like a 1.0.0-1 tag for the build and use in go mod. Increase to -2 and -3 etc 
> for each release candidate we build. Then we add an extra tag 1.0.0 as the 
> official release.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to