Using tags for hotfixes

[bms63]

I created branch from tag

• called it v0_12_1hofix branch
• doing first bug fix with v0_12_1_bugfix1
• could do another bug fix with v0_12_1_bugfix2
• etc...

Assuming that I can then can do a release via my v_12_1_hofix

Once this is deployed we to CRAN - new website. We can merge v_12_1_hofix into main.

[zdz2101]

Language?

[bms63]

Language?

haha - yeah won't be making it into admiral :)

[zdz2101]

Btw @bms63 if you run into issues with deleting tags later https://stackoverflow.com/questions/5480258/how-can-i-delete-a-remote-tag

[bms63]

This all seems pretty straightforward to me and in the end similar to how we did it with pre-release and hotfix branches.

Create Branch off tag at version of admiral we want to patch.

Continue to Branch off newly created patch branch for different hotfixes, doc updates, etc

merge all back into patch branch

create release from patch branch

merge patch branch back into main

...thinking the patch branch has to remain with us forever (can set a rule not to delete them)

[bms63]

I guess if someone wanted to patch 1.0 while 2.0 is out we could do that with this new strategy. So maintain two version of admiral if there is some crazy world we live in that requires that hellscape.

[manciniedoardo]

LGTM - let's make sure to update this section of our documentation once this process is set in stone.

[bundfussr]

Why do you want to include the version in the name of the patch branch?
Why not naming it patch?
Then we have only one additional branch which remains with us forever. Otherwise, we have one additional branch for each hotfix.

And do we need to add the version to the name of the feature branches? I would just use our normal feature branch naming convention, i.e., instead of v0_12_1_bugfix2 use 3456_bugfix2 where 3456 is the issue number.

[bundfussr]

Could we simplify it? (see my comment above)

[ddsjoberg]

LGTM - let's make sure to update this section of our documentation once this process is set in stone.

FYI @manciniedoardo I have an open PR with those updates already 🕺🏼

[bundfussr]

LGTM - let's make sure to update this section of our documentation once this process is set in stone.

FYI @manciniedoardo I have an open PR with those updates already 🕺🏼

I would prefer using a single patch branch as suggested in the PR.

@bms63 , @manciniedoardo , what do you think?

[zdz2101]

LGTM - let's make sure to update this section of our documentation once this process is set in stone.

FYI @manciniedoardo I have an open PR with those updates already 🕺🏼

I would prefer using a single patch branch as suggested in the PR.

@bms63 , @manciniedoardo , what do you think?

Might be easier to use patch notation to trigger all the CI/CD workflows, since as of right now we would need to add it back into all the github actions on admiralci to trigger workflows

For example, right now in admiralci the r-cmd-check.yml is this:

See this PR on admiralci

[bundfussr]

Might be easier to use patch notation to trigger all the CI/CD workflows, since as of right now we would need to add it back into all the github actions on admiralci to trigger workflows

Good point.

By the way, how do the workflows know which version of the upstream dependencies they should use? In the past it was main. With the new branching strategy it should be the latest released version. But the tags may differ depending on the dependency. For example, it could be v0.1.0 for pharmaversesdtm and v0.5.0 for admiraldev. I think staged.dependecies can not handle this because using a branch name like [email protected]@v0.5.0 would be ambiguous.

@cicdguy , @ddsjoberg , any ideas?

[bms63]

Hey all,

So rough instructions for a hotfix:

• patch branch sticks around forever
• Ensure patch branch is up to date with latest release, e.g. v0.12.0
• Bug Fixes are applied to the patch branch via issue-number-patch-fix2, issue-number-patch-fix2, etc and merged into patch
• Submit patch to CRAN to make sure it is accepted
• Complete release via patch branch to redeploy website
• Merge patch branch into main
• Delete patch branch
• ...
• Profit

Other items to attend to:

• CI workflows need patch trigger re-introduced
• Release workflow needs patch branch trigger
• Update documentation on doing a hotfix release
• Ensure patch branch is protected
• Look at how to automate patch update with a major/minor release, e.g. 0.13.0 or 1.0.0,

This stills seems pretty straightforward. Hoping it makes sense to others. We can start patching tomorrow if we are all aligned.

[bundfussr]

We should not delete the patch branch because we will release from it. (See Dinakars comment: #2003 (comment).)

It should be protected and we need to decide when we update it. We could update it after each release. Then it is always ready for a hotfix. Or we update it when we start a hotfix.

[bms63]

We should not delete the patch branch because we will release from it. (See Dinakars comment: #2003 (comment).)

It should be protected and we need to decide when we update it. We could update it after each release. Then it is always ready for a hotfix. Or we update it when we start a hotfix.

Okay so patch branch hangs around. I updated the punch list. I think we are in good shape now to proceed.

[bms63]

I made an issue to update programming docs on how to make a hotfix under our new GitHub Flow Strategy. Going to clsoe this PR