Changelog generator for GitHub milestones
For many years now, I’ve been using Matthew Weier O’Phinney’s changelog_generator script to generate an easy-to-read list of changes for a given milestone. Time has moved on; the Laminas project now uses Laminas Automatic Releases and Matthew hasn’t updated his script since 2013. Since PHP 8, warnings have started appear, so it’s clear updates were required. While I fully intend to see if I can use Automatic Releases on some projects, I have others where this is unlikely to happen and will continue to use changelog-generator.
Looking into it, I worked out that the warnings were from dependent packages. PHP has changed a bit since 2013. My first idea was to simply update to the latest Laminas versions of the dependencies, but I discovered that the Console and Http components are no longer actively maintained, so new components would be needed. I don’t particuarly want to have to do this all again in a few years time when the replacements that I pick don’t support PHP 8.4 or whatever, so I decided to remove the dependencies completely.
Looking at Console, I quickly realised that only one class was used by changelog-generator: Getopt, which worked fine under PHP 8. So, I copied that one class to src, changed the namespace and called it done. For Http, I wrote a new HttpClient class that only makes GET requests using PHP’s curl functions. I’m reasonably confident that the API to those functions won’t be changing signicantly.
While I was messing around, I also fixed a few bugs so that searching by title will look for closed milestones and it now lists the last 20 milestones if you don’t provide an argument. Just a couple of quality of life features to make make it easier for me to use.
My version is now up on Packagist if you need something like this. However, I strongly recommend looking at Laminas Automatic Releases as that automates all the work required for doing a release. If you just need a formatted list of closed issues though, grab this and see if it works for you.
Thoughts on dependencies
My general view is that if it’s not core to your application, then using a dependent package is the way forward. There’s rarely any benefit from spending time working on something that others have already built and to which you are not adding value. This is particularly true for applications where you are adding new features and have better things to do.
However, sometimes this isn’t the right choice. In this case, I need a very small subset of what a dependent package provides. I took the view that maintaining the dependencies would be more long-term work than writing the small components that I actually needed. Particularly, as this tool is stable.
Sometimes this is the right choice for a component in my big projects too.
