Handle multi-stories releases?

[FrancescoCioria]

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 😢

[FrancescoCioria]

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 as version 2 (label? issue name? let's decide how)
  • 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 than v3.x.y
    • throw error!

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)

[giogonzo]

(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? 🤔)

[giogonzo]

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

[FrancescoCioria]

(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 :) )