Package: setuptools-changelog
This project is a setuptools extension which helps to generate change logs from
fragments. This way of changelog management is conflict free, what is extremely
helpful for PR/MR driven workflow.RequirementsPython 2.7, 3.5+;setuptools (31+, but the latest release is better);Your project followsSemantic Versioningor uses it simplified (X.Yversion) form;UsageAddsetuptools-changelogas development dependency to your project;Createchangelog.ddirectory in your project root directory
(wheresetup.pyis located)Create there fragments files according the changes you made. Fragments files
have the following format:{name}.{type}.{ext}Where:name: fragment name. If itstartswith a number and you have
issue tracker specified, this number will turn into issue reference
automatically. Otherwise there could be just some mnemonic name to
simplify navigation.type: fragment type. By default, the following types are availableMajor changes:epic: Massive epic change that completely changes underlying
project platform. This could be a shift to completely new base
library, framework, etc. Epic changes are very rare and are the reason
for major release.breaking: Breaking change means changes in the projectpublic APIwhich makes old code incompatible with them.
Incompatibility means that things were removed or their behavior had
changed.Minor changes:security: This is an important security fix. Users must update
ASAP. If security fix causes breaking change, two separate changelog
fragments should be issued.deprecation: Deprecations are friendly warnings about upcoming
breaking changes in the public API.feature: New features brings something to project and they must be
available for users via public API.Patch changes:bug: When something works in the way it’s not expected or supposed
to we do a bug fix.improvement: This could be speed optimizations, internals
refactoring, making code more stable etc. Improvements are never
changes the existed behaviour or public API.build: Changes, related to project build routines, packaging,
etc.doc: Documentation updates, clarifications, typo fixes, etc.test: Work around project testing, test suite, CI, etc.misc: Misc changes which doesn’t suites any existed category.
For instance, they could be announcements about project life: new
committers, endorsements, etc.ext: file extension. Currently, we support onlyrstone.You can always preview changelog via:python setup.py changelogOnce you’ll be ready for release, you can update your changelog file like:python setup.py changelog --update=CHANGELOG.rstThis command willprependgenerated changelog to your file.Review your changelog file content and everything is fine commit it and
remove fragments:git rm changelog.d/*
git commit CHANGELOG.rst changelog.d/Example configuration forsetup.cfgusing defaults:[changelog]
changelog_fragments_path = changelog.d
major_changes_types =
    epic = Epic Changes
    breaking = Breaking Changes
    removal = Breaking Changes
minor_changes_types =
    security = Security Fixes
    deprecation = Deprecations
    feature = New Features
patch_changes_types =
    bug = Bug Fixes
    bugfix = Bug Fixes
    improvement = Improvements
    build = Build
    doc = Documentation
    test = Tests Suite
    misc = MiscellaneousAutomatic version generationIf your project followsSemantic Versioningstrategy, you can achieve not
just changelog generation, but also automatic version management depending on
changes it has.Integration withtowncrierThis project was started because there are several reasons for me to not usetowncrierfor changelog management. ButWhy have enemies, when you can have?—King Arthur: Legend of the SwordInstead, we can support fragments, made for towncrier with the following
config:[changelog]
changelog_fragments_path = changelog.d
major_changes_types =
    removal = Breaking Changes
minor_changes_types =
    feature = New Features
patch_changes_types =
    bugfix = Bug Fixes
    doc = Documentation
    misc = Miscellaneous
use_towncrier = trueAnd that’s it!