Release 1.12

Scott Wheeler scott at taglib.org
Sun Nov 29 16:04:33 GMT 2020



> On 28 Nov 2020, at 12:21, Urs Fleisch <urs.fleisch at gmail.com> wrote:
> 
> It would be nice if we would see a release 1.12 of TagLib in the near future. Are there some tasks (e.g. bug fixes, tests, ...) with which I could support the work on the next release?

The honest truth is that TagLib needs is a new maintainer.  I stopped being the primary maintainer 12 years ago, when Lukas and later Kageyu took over, but I haven’t heard from either of them in a few years, and I drifted back into doing occasional TagLib work.

Doing a release is usually a few days of full-time work, and with the pandemic at the moment, where my kids have spent big chunks of the last year at home and it’s hard to find enough time to do my actual job, finding multiple days to dedicate to TagLib hasn’t been possible.

That said, in contrast to previous times I’ve said this (on Github), at least at this moment my kids are going to day-care, and I have a big release coming up for my work project this week, so at least possible to imagine I could find some time in mid-December.

When I’ve run the releases, usually the process is something like this:

- Review pull requests, focusing on bug fixes.  If a bug fix is good in code-style and approach, merge it directly, otherwise clean up and merge.  I’m very cautious with optimizations since they have a tendency to introduce bugs in a relatively stable code base, keeping in mind that a particularly bad bug can destroy someone’s music collection.  Features also have to be filtered through the, “Is this something that someone will be widely used and maintained in the future”-filter.  Close or tag things I don’t intend to immediately merge.

- Go through bug reports and see if there’s anything really critical that should block the next release (i.e. file corruption, reproducible crashes).  Again, when doing this with other people, using tags to sort them is useful.

- Review the complete diff from one release to the next.  That usually takes a while, but I’ve caught a lot of bugs that way.  It’s often also a good time to catch style inconsistencies, and new functionality that’s missing API docs.

- Go through the commits and turn them into a changelog.  The other folks working on TagLib were generally better about updating the news file than I was.

- Generate docs and update website.

Nothing in there is rocket science, but like I said, it is a few days of work.  If you’re interested in jumping in and starting to handle some of that stuff, great.  :-)

-Scott


More information about the taglib-devel mailing list