Generate changelog for last x feature releases

[ite-klass]

convco changelog has the parameter --max-versions.

When using semantic versioning, version numbers are split into major, minor and patch versions for breaking releases, feature releases, and pure bugfix releases.

When releasing 2 feature releases and then 5 bug fix releases, --max-versions 5 would only list the bugfix releases.

Depending on release workflows, parallel supported versions, and actual releases, it can make sense and be preferable to include the last x major or minor releases, and all related bugfix releases.

Personally, I would like to generate a changelog for 3 minor releases, while including any bugfix releases that happened in between/after them.

Is this something you would be willing to add?
Although it adds interpretation of version numbers, semantic versioning is quite popular, and possibly not listing the last feature release when using --max-versions seems like a significant issue to me - a hole in/for such a use case.

[ite-klass]

I see --prefix already does semantic interpretation or expects semantic versioning.

    -p, --prefix <PREFIX>
            Prefix used in front of the semantic version [default: v]

[hdevalke]

The prefix is only used to parse the number out of the tag.

maybe --max-minors or --max-majors could be added. you could always specify a range (v2.0.0..) to show/check all changes after v2.0.0

[ite-klass]

The advantage of --max-x is that it’s relative. Specifying the git baseline requires logic integrating with git and ci at least.

[ctron]

I would also be interested in a similar functionality. My use case is to create up a changelog up until the latest non-milestone release.

To my understanding, currently I can use --max-versions=1 to render a changelog "for this release". However, if I do milestone releases, that would no longer works, as I would only get the changelog between the release and the last milestone release.

So maybe something like: --max-versions=1 --dont-count-milestones (which is a weird name, just to give an example).

[ite-klass]

What is a “milestone” or “milestone release” in your case? And how, if at all, does it relate to semantic versioning with major.minor.patch version numbering?

[ctron]

Ok, call that "pre-release" in the Rust world: https://doc.rust-lang.org/cargo/reference/resolver.html#pre-releases

[ctron]

Same for Go: https://go.dev/doc/modules/version-numbers#pre-release

[ite-klass]

That makes sense, to exclude pre-releases when counting tags/releases for changelog generating. It’s the two sides of a minor release; pre-release before, and patch release after.

So, with both cases in mind,

convco changelog --max-versions 1 --dont-count-prerelease --dont-count-patch

An alternative could be

convco changelog --max-minor-versions 1

[hdevalke]

Pre-release versions are interesting, if one would print a changelog of the last major it should ignore the current pre-release versions, but include the pre-release versions of that major.

e.g. we have the versions 1.x.x, 2.x.x-alpha, 2.x.x and 3.0.0-alpha

--max-major-versions 1 --ignore-pre-release should only print out version 2.x.x.-alpha until including 2.x.x and only ignore the current pre-release versions. If it would be a 3.1.0-alpha it should print a changelog of 3.0.0 until excluding 3.1.0-alpha.
--max-major-versions 1 just prints the changes as from >2.x.x (excluding 2.x.x).

same logic to be hold for --max-minor-versions

[hdevalke]

@ite-klass and @ctron #79 does implement the --max-majors/minors/patches

If multiple flags are combined the first one that is reached will make the changelog generator stop e.g. convco changelog --max-minor 2 --max-patches 2 will show v0.3.11 and v0.3.10 for convco and not show v0.2.2 and v0.2.3. I think that is the most logical option, otherwise i could make the flags conflicting with each other, so you can only specify 1 flag at a time.

I still have to implement the --ignore-pre-release.

[ite-klass]

I think this ticket / the original request is implemented with --max-majors 2?

I think this ticket should be closed as implemented then. If you still plan on --ignore-pre-release that could be a separated, dedicated issue ticket.

[hdevalke]

Indeed a new issue can be opened if this feature is still wanted.