Handle multi-stories releases?
Opened this issue ยท 4 comments
requirements
Some complex repos (ex: npm
) keep supporting old versions.
This is a problem if you want to use smooth-release
as the breaking logic considers only the breaking issues closed after the last tag, but in these kind of repos the last tag may refer to older versions.
Should we try to link an issue to its correct "story" or simply document this and add a config param to disable the breaking-detection logic in case user plans to support multiple versions?
specs
It's really too complicated (and maybe impossible)... => let's just document this situation clearly and add a config param to disable the breaking-detection logic ๐ข
Or, we could improve the logic for "breaking-detection" and "changelog" as follows:
- analyze tags to get highest
npm-version
tag (ex:v3.x.y
)- if current version is one or more
major
steps lower (ex:v2.x.y
,v1.x.y
,v0.x.y
) -> we are in a separate "story"- ignore issues closed after last
npm-version
tag of that story (ex:v2.1.0
) unless they're marked asversion 2
(label? issue name? let's decide how)
- ignore issues closed after last
- if current version is the same (exactly:
v3.x.y
) -> we are in "main story"- ignore issues marked as lower versions
- if current version is higher than
v3.0.0
but lower thanv3.x.y
- throw error!
- if current version is one or more
This would also mean that we should improve the branch validation to handle multiple base branches (ex: "branch": ["master", "v2", "v1"]
)
@giogonzo, what do you think? Too complex?
we could mark issues for "old stories" in multiple accepted ways:
- label
v2
- issue title start with
v2:
- issue title ends with
(v2)
if an issue as at least one of those it will be considered as part of that "story" (and branch)
(we already had this discussion offline but I'll add it here too)
Seems feasible/reliable, although maybe a bit over-complicated (in the end the multi story one is not our standard use case).
I still have the feeling that the easiest way to support a git history is by working on git commits (not github issues).
Afterall, if considering only merge commits we'd still have the same functionality we have now (and data to generate links in changelog), except for the breaking detection logic (but even here, what if someone like hophop or nemobot is in charge of updating the merge commit message with "breaking" if needed? ๐ค)
just bumped into this related work so I'll leave it here https://github.com/fritzvd/standard-version/blob/3116e4fdab3bf43bf7aca3206e1053dd9f61d444/README.md#release-on-a-seperate-branch-like-release20-or-hotfix-parsing-lists
(but even here, what if someone like hophop or nemobot is in charge of updating the merge commit message with "breaking" if needed? ๐ค)
Actually for buildo's workflow we already have everything as every merge commit contains the id of the associated issue (if it has one, of course) so in that case we can still use GitHub's API to retrieve the issues and look at them or, even better to be buildo-tools-agnostic, get the PR with GitHub's API by using the branch it was merged from and look for a bug/defect/breaking/... label on the PR itself as we're currently doing for the issues (at buildo these labels are automatically added to the PR by nemobot so no additional work for us :) )