Changelog for build versions
Moderators: Developer, Contributor
Changelog for build versions
How to configure change logs to create logs per build version, please?
Re: Changelog for build versions
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?
* 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?
Re: Changelog for build versions
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:Like most software companies we publish more than hundred updates together with a changelog for each minor update.
I don't think so.Knubbi wrote: Is there an easier procedure we miss
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
...
Re: Changelog for build versions
Not necessarily per year but per major version. Never saw a software release with a version number like 4.5.132?I don't understand what you mean with "more than hundred updates".
Users may need to know what changed between 4.5.132 and 4.5.133
Re: Changelog for build versions
Quite unusual, at least if you follow the rules of semantic versioning (www.semver.org).Knubbi wrote:Never saw a software release with a version number like 4.5.132?
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?
Re: Changelog for build versions
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.
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.