Hi @koral,
the step changelogs are semi auto generated. We have a tool which collects the changes from the steps github release pages (then we review/reformat the generated changelog).
Not documented as it’s not a final solution - not used anywhere else, only in our monthly updates, where we collect the changelogs with a custom script. The CLI itself does not require this nor does it handle it in any way.
To be honest we’re not sure this should be the official solution, given that it would only work with GitHub releases, while all of the StepLib tools are written so that any git hosting can be used.
BTW if you have an idea for a pure git based solution, without depending on git hosting specific features just let us know!
For now we’re thinking about building this into the CLI, as part of a bitrise :step share plugin command which would replace the current sharing procedure. It’d do the same thing internally, but could interactively ask for the version number and probably for a release notes. Ideally it’d even support multiple sources for the release notes, including GitHub releases, a CHANGELOG file or simply terminal input.
Collecting commit messages between current and previous version tag. That may be one of the sources which may be chosen apart from [quote=“viktorbenei, post:6, topic:2018”]
release notes, including GitHub releases, a CHANGELOG file or simply terminal input
[/quote]
For example HockeyApp Jenkins plugin has such feature as one of the choices for release notes.
That’s a good idea for an option, but wouldn’t make that the default - from our experience this would create insanely noise release notes for most steps. But as an option in the step share plugin, definitely!
Yeah, there is probably no good universal default because each author may prefer different solution.
Maybe CLI can remember that choice for given step id locally and default to previously selected one.