Tagged releases

[DanH42]

Like many others, I experienced problems when this extension got updated to MV3 on my devices. Everything was fixable on my end and/or is already covered in existing issues, but as I was digging into things, it took a bit of extra effort to piece together what had changed when due to the lack of tagged releases or a changelog. It wasn't terribly difficult just looking through the commit log, but there were still some oddities (for example, a quick skim might lead you to assume the last version was 1.7.4 released October 6th, because the commit for 1.8.0 doesn't mention a version bump in its message).

The main benefit would simply be informational: if I know the extension updated recently and I'm having trouble, the first thing I want to know is what changed. This could be communicated via e.g. a CHANGELOG.txt in the root of the repo or even just a ## Changelog section in the readme, either of which would be a small step in the right direction on its own. However, proper tagged releases would also remove some guesswork if someone's trying to pull and build an older version of the extension to troubleshoot something locally, or to directly compare/verify exactly what changed in the code.

This would be more of a process change than anything else, so unfortunately I don't think there's much I could put together as a PR to help out; you know your workflow better than anyone else. As for backfilling a changelog up to today, my guess is you've got more context on what changed when and why, but I could probably take a stab at putting something together from past commits if time is a major blocker for you.

[DanH42]

As a bonus, GitHub releases would also help pave the way toward being able to provide direct .crx/.xpi downloads of specific versions for the handful of users who might want such a thing (as in #118). That would also be more convenient for users who want to run the non-default manifest version for their platform, like keeping MV2 on Chrome, to avoid any of the issues caused by limitations of MV3 (as seems to be the case in #110).

My personal preference in these sorts of situations is to just load unpacked extensions from source, since it gives me more control over updates than the Chrome devs want users to have, and updates are just a git checkout away, but I've heard a lot of other folks prefer packaged copies. In either case, releases are also a benefit because they let me subscribe to notifications about only those on GitHub so I know when to update things without needing to follow an entire project.

[tom-james-watson]

I guess it would be ideal, yes. But honestly, it is what it is. I won't be going back to fill in anything historical. Next time there's a code change, I'll try and remember to tag a release. But yeah, ultimately this is a simple extension and wanting to do anything special like what you describe is going to be rare enough that I don't want the extra maintenance, honestly!

I'm not aware of any issue that is new to the manifest V3 version. The one you linked was for manifest v2.