ChangeLog

[jubalh]

Let's add a ChangeLog/NEWS file please so we know what changed between versions.

[mdadams]

A ChangeLog is already included in the official Tar/Zip archive distributions of JasPer. For example, see the ChangeLog file in https://www.ece.uvic.ca/~frodo/jasper/software/jasper-2.0.14.tar.gz
The ChangeLog is not stored under version control, since it can be generated from by the git command.
If you are not comfortable using the git command to generate the ChangeLog, then I would recommend downloading an official release archive from the following site (which already has a ChangeLog generated):
https://www.ece.uvic.ca/~frodo/jasper/#download

[jubalh]

Right, this is good to know. I missed that (also due to some of the reasons mentioned below).

In my opinion there are a couple if mistakes here:

• https://www.ece.uvic.ca/~frodo/jasper/software/jasper-2.0.14.tar.gz exists but neither do https://www.ece.uvic.ca/~frodo/jasper/software/jasper-2.0.15.tar.gz nor https://www.ece.uvic.ca/~frodo/jasper/software/jasper-2.0.16.tar.gz
• Latest release (2.0.16) is only available from GitHub at https://github.com/mdadams/jasper/archive/version-2.0.16.tar.gz which is the tarball generated by GitHub without any ChangeLog file. You should upload your own tarball to the release page on GitHub. If the ChangeLog would be added to git after its creation it would now also be in the auto-generated tarball ;)
• The ChangeLog contains merge commits
• The Changelog was not edited so it litsts for example 910c351 although this has been reverted by fc03b57 I think both such changes should just be ommitted in the ChangeLog

[jubalh]

I think this issue should be reopened and processed.

[mdadams]

My personal feeling is that the ChangeLog should be just that, a log of changes made to the code (i.e., the information taken directly from the commit log messages). It should not require manual editing. To date, no official release tar archives for JasPer have ever been placed on GitHub. They are only available via my JasPer project home page at UVic (http://www.ece.uvic.ca/~mdadams/jasper). The so-called "releases" on GitHub are not true releases per se. They are only tags in the Git repository. I tag the repository more frequently than I generate official releases so that package managers (e.g., for Linux distributions) who build JasPer directly from the Git repository can build from a more recent (tagged) version of the code than the last official release. Of course, another solution would be that I tag the repository only when I make an official release, but I think that my current practice is better.

[jubalh]

If you tag them as -beta or -rc it is more visible that you intend them to not be releases. If you name them like regular release people assume that it's a regular release.

You can see here, that several distros (Arch, Gentoo, Haiku, Manjaro, Parabola, Slackware..) all thought that your tag of 2.0.16 was meant to be a release. All of those packaged it already and ship it in their distro.

My personal feeling is that the ChangeLog should be just that, a log of changes made to the code

I agree, a ChangeLog is the change from a certain version (release) to another. So if one makes a change and reverts it again there was actually no change between the first release and the next, so I would say such things should be omitted. I think this is more helpful since it shows clearer what was changed between versions and not how many commits developers needed to achieve a change.

[mdadams]

You have misunderstood. The tagged versions should absolutely be picked up by package managers for Linux distributions. Thet is the main reason that such tags are there. My point is that people doing packaging know how to generate a changelog from git if they want one. I don't maintain a NEWS or ChangeLog file by hand, and I don't intend to do so, since I know myself well enough to know that I will forget many important things in it and it will get out of date. So, I rely on a changelog automatically generated from git so things do not get missed or out-of-date. Since the changelog is automatically generated, it would not make sense to put it under version control. I only generate the changelog in the tar archive distributions for the general public (who might not be able to generate a changelog for themself using git). These tar archives are less likely to be used by package managers, since package managers likely prefer to pull code directly from a git repository.

So, in short, all tagged versions of JasPer are fine to use and I encourage people to use the most recently tagged version if they can (and the latest tar archive otherwise). But I do not generate a tar archive for every release. I just don't have time. :(

[jubalh]

You have misunderstood. The tagged versions should absolutely be picked up by package managers for Linux distributions.

Sorry! Misunderstood you indeed.

My point is that people doing packaging know how to generate a changelog from git if they want one.

It is not about knowing how to do it. If upstream has a ChangeLog all downstreams can use the same ChangeLog. Also there is no duplication of work and it has just to be done one time.
And still my point about changes from version to version and not the commits themselves are relevant to end users. Even more so when people dont write git commit descriptions well.

These tar archives are less likely to be used by package managers, since package managers likely prefer to pull code directly from a git repository.

All package maintainers prefer release tarballs. Noone pulls from git and creates the tar themselves. It is just that GitHub has this feature to create releases from git tags and people use this tarball then.
But it is still expected that this tarball holds all the information.

I just don't have time. :(

I understand. While I still don't have the same opinion as you do on this, I suppose there are more pressing issues at hand to handle. So..okay let's focus on them.

Maybe you can find some time soon to look at the open pull requests? Or find a student of yours who you could delegate this task to? Or add more maintainers to the repo?

[mdadams]

Incidentally, the script that I use to make tarballs is the make_dist script in the build directory of the Git repository for JasPer. So, if anyone is really desperate, they can generate a tarball if they need it. It is just that I don't really have much time to work on JasPer. So, I would rather spend the little time that I do have to deal with fixing bugs and processing PRs, rather than building and validating tarballs. It's not that some of your comments are not valid. It's just a matter of time on my side. I guess that the package managers are using the tarball generation feature of GitHub because some Linux distributions are using tagged versions of JasPer that do not correspond to versions with tarballs.