towncrier
semantic-release
towncrier | semantic-release | |
---|---|---|
5 | 77 | |
734 | 19,834 | |
1.0% | 0.9% | |
7.6 | 9.4 | |
7 days ago | about 22 hours ago | |
Python | JavaScript | |
MIT License | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
towncrier
-
Changelog-Driven Releases
I don't really like writing the change log automatically from commits. I think those both have a slightly different audience and thus need different wording.
I know the frustration of merge conflicts on the change log file.
Right now, I'm creating change logs by hand which is time consuming to do on release time. I'm considering switching to using towncrier or something similar, where you have a changes dir with one file per change for creating change logs --> https://towncrier.readthedocs.io/
-
towncrier VS cf_changelog - a user suggested alternative
2 projects | 10 Jan 2024
-
What are some examples of good release notes from open source projects that you have come across?
Here is an example of another decent one. Not perfect, but it is generated with TownCrier, so it is easy to maintain.
-
The Subtle Art of the Changelog
We used to... somewhat attempt manual changelogs. Every time it came to a release the release manager would ask around for what the key changes were, and we usually ended up with only a couple of entries.
Now, we use https://github.com/twisted/towncrier . Every change goes through pull requests, and every PR must have a newsfragment file - and we enforce this with a test that fails if it isn't present (with convenience functions of rewriting the number to match the PR if you name the news file XXX.{category}). If it's not a user-facing change, then we just have a category that is ignored.
On releases (or on individual PRS along the way), the release manager generates the changelog, but also edits them into a relatively coherent style (or rewrites developers news fragments along the way).
Every change has a note written aimed at the user. Every entry in the changelog has a link to the relevant PR or commit. We have much better changelogs now.
-
Changie - Automated Changelog Tool
Twisted's Town Crier is a generic tool
semantic-release
-
Git commit helper: add emojis to your commits
Using Conventional Commits โญ as a standard for your commit messages, makes Semantic Versioning ๐ as easy as can be, with tools like Conventional Changelog ๐ Standard Version ๐ and Semantic Release ๐ฆ๐
-
๐กAutomatic Deployment of your project dependencies updates on GCP : Efficiency vs. Cost?
Auto-tagging a project, Renovate or Dependabot can do this. With a Git Workflow and another tool like semantic-release you can do this. This behavior is a โgymnasticโ to do on the CI/CD of your project but itโs not complicated. For example with GitLab CI, you can verify the pipeline run on the default branch of your project :
- alacritty-themes not working any more!!!
- Announcing @ngneat/avvvatars
- Auto versioning?
-
Is it possible to bypass merge queue requirement for a GitHub app without needing admin permissions?
I'm trying to improve the security behind our release process, which uses semantic-release. During this process, it creates a change log which is committed to the repo, publishes a package and a few other things.
-
How to set up Commitzen with Husky
Conventional commits specification contains a set of rules for creating an explicit commit history, which makes it easier to write automated tools on top of, for example, semantic release. You can manually follow this convention in your project or use a tool to assist you, such as Commitizen.
-
Automated release with Semantic Release and commitizen
When working with JavaScript projects, managing version numbers and commit messages is important for the maintainability of the project. Since 2020 I have been the main developer of Atomic Calendar Revive a highly customisable Home Assistant calendar card, I found maintaining versions and releases to be cumbersome until recently. In this article, I will introduce the commitizen and semantic-release packages for creation or appropriate commit messages and semantic versioning. I will also provide examples of how I am currently using these packages to streamline my release workflow and project maintenance.
- ๐ฆ Effortless Data Quality w/duckdb on GitHub โพ๏ธ
-
How I Sliced Deployment Times to a Fraction and Achieved Lightning-Fast Deployments with GitHub Actions
To further streamline deployments, I introduced semantic-release. This tool automates commit tagging and tracks changes since the previous version. As a result, deployments now occur only when new tags are present, saving us valuable minutes.
What are some alternatives?
standard-version - :trophy: Automate versioning and CHANGELOG generation, with semver.org and conventionalcommits.org
GitVersion - From git log to SemVer in no time
changie - Automated changelog tool for preparing releases with lots of customization options
conventional-changelog-config-spec - a spec describing the config options supported by conventional-config for upstream tooling
Release It! ๐ - ๐ Automate versioning and package publishing
nextrelease - One-click release publishing by merging an automated PR.
release-drafter - Drafts your next release notes as pull requests are merged into master.
semver - Semantic Versioning Specification
commitlint - ๐ Lint commit messages
pyscaffold - ๐ Python project template generator with batteries included
gradle-git-versioner - A Gradle plugin to automatically version a project based on commit messages and semantic versioning principles