I’ve noticed that most (if not all) of the community created steps have empty change lists in CLI changelog. E.g. in the latest one: Monthly release of Bitrise CLI tools and summary of updates (Jun, 2017) - CLI v1.6.2
Is it intended or is there a place where step changelog should be located to be picked up but none of the step maintainers filled it?
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).
OK, is that documented somewhere?
Such information should be written in https://github.com/bitrise-io/bitrise/blob/master/_docs/step-development-guideline.md perhaps.
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.
OK, thanks.
Any time 
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.
Definitely a great idea! 