I'm dealing with a legacy Python application and our company recently enabled Branch Protection across all organizations with GitHub. This change has disrupted our old versioning workflow. Previously, we used a Jenkins script to handle version updates: it would bump the version for releases by stripping out the '.dev' suffix and then push it to master before bumping it back to a '.dev' for the next increment. Now, this method isn't feasible. I'm looking for a workaround that avoids manual versioning, if possible. How are others managing semantic versioning during releases under these new governance rules? I considered building a custom app to automatically bump the version, create a new pull request for master, and then bump back to '.dev', but that feels excessive. Any thoughts?
6 Answers
You could try using Semantic Release, which integrates well with CI tools. With this setup, you maintain two branches: 'dev' and 'main'. It auto-generates version tags based on your commits, like moving from 'v1.0.0-dev.X' to 'v1.0.0' for releases, and it also creates a changelog from your commit messages. It's a robust alternative to help automate your versioning process!
Honestly, I think it's good to keep the Branch Protection in place. Instead of working around it, consider creating release candidate tags and deploying those to staging. This lets you test thoroughly before merging into the main branch, ensuring a smoother deployment to production later.
I prefer a convention that makes sense for the team: something like '...'. This way, we develop logical versioning based on the deployments, and it keeps everything organized. For our charts, we let the pipeline handle version increments automatically, maintaining clarity on what's running in production.
I don't think your idea is overkill at all! In fact, it sounds like a solid approach that aligns with how teams handle governance under Branch Protection. You should automate the bumping of the version and the creation of the PR. Once the PR is approved and merged, you can set up a post-merge hook to bump the version back to '.dev' and create the next PR. It's a slower process, but it ensures everything stays auditable and compliant with the new rules. Plus, consider adding a slash command for triggering this action easily! You're not building something excessive; you're building a disciplined workflow.
By the way, check out the NoFluffWisdom Newsletter for insights on devops automation under tight governance—it could be useful!
We don’t follow semver either; we just tag each commit to master. Each new commit has its own version, making things straightforward since it’s just tagged with the commit ID. It keeps things simple without the complications of manual versioning!
If you're open to alternatives, have you tried using timestamp-based releases? Your release script could find the version from your code and apply a format like 'v20250805T142813', which updates every second. It can simplify things if you’re working with point-in-time releases instead of semantic versioning. For aspirational releases, you can still document your features in a ReleaseNotes file to guide the versioning. Good luck with your project!
Thanks for the suggestion! I’ll check out that newsletter. Sounds like a productive way to spend my work hours!