How would I make a hotfix/patch release to an older branch/release

[fritzvd]

Hi,

Is it possible to be able to release from a fixes/hotfix/stable whatever branch?

E.g. master is ahead at 4.3.1. But I'm looking to release a security patch to 2.0.1 from a release2.0 branch for it to become 2.0.2.

How would I go about that in standard-version? Or is that scenario not supported?

Fritz

P.S. I've been looking through the issues, and the most similar ones to mine are those about named versions (#83, #84). But that's not what I mean.

[stevemao]

You could switch to release2.0 branch, do commits on the branch and release. It should generate the right changelog. Merging it back to master might be a bit tricky I think. You'd need to resolve the conflicts in CHANGELOG.md
linking: conventional-changelog-archived-repos/git-semver-tags#10 (comment)

Am I missing anything?

[fritzvd]

Thanks @stevemao. That makes sense.

[stevemao]

@fritzvd does it work for you? Is this resolved?

[Tapppi]

This should work at the moment as is, right @fritzvd? I think the right workflow in this situation is to:

• make the fix on a separate branch e.g. hotfix-crash-on-startup-23
• merge this to the earlier release2.0 branch
• run standard-version which should pick up only the tags on that branch, and release a correct CHANGELOG.md and version.
• if possible merge the hotfix branch to your other release (master/release2.1/release3.0 etc.) or rebase and ff-merge and repeat the standard-version process.

This avoids conflict between changelogs etc. as the same hotfix is just applied to multiple branches of release. IMO that is the correct workflow and should be supported by standard-version explicitly (right now this seems to be pretty obtuse and implicitly supported). As explaine in conventional-changelog-archived-repos/git-semver-tags#10 (comment) having that pull requests result as default in standard-version would break this workflow with no alternative I can see? As such I still am of the opinion that the functionality should be in git-semver-tags as an option and disabled here until other concerns such as this issue are resolved.

Unless there is a dissenting opinion I think this can be closed as soon as someone verifies that my assumption about this working right now is correct?

/CC @bcoe @nexdrew @stevemao

[Tapppi]

BTW we should probably document the working workflow. so:

• release from master and if you want individual release2etc. branches
• Do not cut releases from other branches, as they will screw up your history (if this is mandatory, you need to somehow get to git-semver-tags and enable the "all branches tags" option).
• Use the feat hotfix git flow for merging to multiple release branches and cut releases from there to ensure intact CHANGELOG and versioning.

Sorry for the walls of text but just realised that this isn't as explicit as I thought it would be. It just happened to fit into my personal and our work workflow perfectly 😅

[fritzvd]

Yes that would work. Thanks for clarifying. That helps a lot Op 2 dec. 2016 20:56 schreef "Tapani Moilanen" <notifications@github.com>:

…

This should work at the moment as is, right @fritzvd <https://github.com/fritzvd>? I think the right workflow in this situation is to: - make the fix on a separate branch e.g. hotfix-crash-on-startup-23 - merge this to the earlier release2.0 branch - run standard-version which should pick up only the tags on that branch, and release a correct CHANGELOG.md and version. - if possible merge the hotfix branch to your other release (master/ release2.1/release3.0 etc.) or rebase and ff-merge and repeat the standard-version process. This avoids conflict between changelogs etc. as the same hotfix is just applied to multiple branches of release. IMO that is the correct workflow and should be supported by standard-version explicitly (right now this seems to be pretty obtuse and implicitly supported). As explaine in conventional-changelog-archived-repos/git-semver-tags#10 (comment) <conventional-changelog-archived-repos/git-semver-tags#10 (comment)> having that pull requests result as default in standard-version would break this workflow with no alternative I can see? As such I still am of the opinion that the functionality should be in git-semver-tags as an option and disabled here until other concerns such as this issue are resolved. Unless there is a dissenting opinion I think this can be closed as soon as someone verifies that my assumption about this working right now is correct? /CC @bcoe <https://github.com/bcoe> @nexdrew <https://github.com/nexdrew> @stevemao <https://github.com/stevemao> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#130 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJySPtTjRnwzqSyVCLrwRu9u0-huJOgks5rEHfggaJpZM4KYsMl> .

[bcoe]

@Tapppi @fritzvd want to perhaps take a stab at editing the README a bit to reflect this?

[fritzvd]

Sure. Good idea. I'll find some time tomorrow Op 3 dec. 2016 23:28 schreef "Benjamin E. Coe" <notifications@github.com>:

…

@Tapppi <https://github.com/Tapppi> @fritzvd <https://github.com/fritzvd> want to perhaps take a stab at editing the README a bit to reflect this? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#130 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJySEd4akYF_oKzAt6ClnqU_Y4a1DpRks5rEezygaJpZM4KYsMl> .

[hjylewis]

Sorry if this is already answered (I had a hard time following the git-semver-tags stuff), but is there an easy way of merging the changelog entries from the older release branch back into the master changelog?

For context, I added a patch to an older release and now I want that release to be documented in the master changelog. It's in the changelog in the release/x branch but not in master.

[bcoe]

@Tapppi I don't suppose you could be enlisted to add your notes to the README, I never feel like I fully followed what might be an appropriate workflow for hotfixes either.