Hmm …

My project pages have this “Downloads” section and I offer tarballs for each release:

https://movq.de/git/jenny/#downloads

I added this many years ago because an OpenBSD dev asked for it (but the project in question didn’t end up in their ports after all).

What are your thoughts on this? Is it necessary to offer tarballs?

I noticed that some distributions have already moved away from using tarballs and instead always clone from Git. 🤔

@david@daiwei.me Oh, that is a good idea. This could be included here, yeah. 🤔

@david@daiwei.me Is this better? 🤔 Pretty hard to keep this concise but also not miss anything. 🤔 https://movq.de/git/jenny/

I’ve stopped providing tarballs for branches now. This was pretty pointless, I think.

@movq@www.uninformativ.de Good question. Tarballs are probably not needed, but might be convenient for people who don’t want to or can use a version control system. Not sure if there are non-techies who use your software. Tarballs for branches are overkill, though, I agree.

Looking at this more closely: As for the feeds, how about filenames “tags.atom” and “commits.atom”? Unless, of course, they were already named like that before.

For the tags feed it would be cool to include the actual changelog entries to be more useful if somebody takes this approach to get notified of new versions. But that would mean you have to duplicate the changelog entry into the annotated tag. And then you can’t fix changelog typos in the feed anymore. Alternatively, the feed generation would need to extract the section from the the CHANGES file. That has the benefit of automatically providing changelogs for past versions in the feed.

@lyse@lyse.isobeef.org Yeah, the feed names are legacy and I didn’t want to set up redirect rules. (I can’t really tell if anybody actually uses them …)

Extracting the info from the CHANGES file would be nice. Maybe I’ll add that. :-)