Mantis Bug Tracker - Forums

How to configure change logs to create logs per build version, please?

There is no configuration option for change log to get what you want.
You would have to change source code or write a plugin.

Like most software companies we publish more than hundred updates together with a changelog for each minor update. This sounds like a very common requirement/procedure.

* Mantis can make changelog per version number but it is very uncomfortable for developers to switch from editing an issue, switching to product configure to add a new version number to the database and then going back to finish the issue ticket.

* Using builds makes entering Update versioning easy but there is no changelog feature.


Is there an easier procedure we miss or is it this difficult to use?

Knubbi wrote:Like most software companies we publish more than hundred updates together with a changelog for each minor update.

I don't understand what you mean with "more than hundred updates". Is this in one year? If so, this is certainly not what most software companies do.

Knubbi wrote: Is there an easier procedure we miss

I don't think so.

Whenever you miss something, there are a lot of options to get what you want, e.g.
- create a feature request at https://www.mantisbt.org/bugs , fork from https://github.com/mantisbt/mantisbt and send a Pull Request
- write a plugin
- write a custom function (easier than plugins for some use cases, but no longer recommended as custom functions are deprecated and might be removed in future versions)
- change source code
- use SOAP API
- use REST API
...

I don't understand what you mean with "more than hundred updates".

Not necessarily per year but per major version. Never saw a software release with a version number like 4.5.132?

Users may need to know what changed between 4.5.132 and 4.5.133

Knubbi wrote:Never saw a software release with a version number like 4.5.132?

Quite unusual, at least if you follow the rules of semantic versioning (www.semver.org).
Having 132 patch versions for a single minor version would be quite a lot.
What does 132 mean in your case? Is this no version number but a build sequence?

4.0.132 would be the 132th public release of major version 4. Major versions may have a release term of around 24-36 months.

We publish around one update every week and users wish to see a changelog between all those versions to figure out whether applying the update is worthwhile for them.

Unusual? Our software has millions of downloads.

--

Thanks for the tip with http://semver.org/ - Sounds like a good idea to use version numbering to inform about (non) backward compatibillity.