Time for a new release?

[ilovezfs]

Just noticed that you'd moved the project to GitHub and was going to update the Homebrew formula accordingly, but the Git history indicates that the only release tag here on GitHub, 1.0.7, is a dud, so I'm wondering if it might be worth creating a new tag that includes the revert to 1.0.6 but that is > 1.0.7 to avoid confusing our livecheck system which will flag this for upgrade if I switch it over to GitHub.

[cslarsen]

Sure, I can create a new version number with a tag and push that. Is that all you need? Do I need to create any tarballs, other stuff? I've never made a release for jp2a on Github before, so I'm not exactly sure how to do it (e.g. several tarballs with different compressors, zip-file, etc). I won't do binary releases anymore.

Do package manager ever run autoreconf? I would guess you need a proper tarball made with make dist? If that is what you need, along with a v1.0.8 git tag, I can do it if you can give me some pointers to docs on how to do this properly.

[ilovezfs]

Is that all you need?

Yup. A release tarball is nice to avoid having Autotools dependencies, but it's not required by any means. We can run autoreconf if only the source archive tarball is available.

The source archive tarball (and the source archive zip file) become available immediately from GitHub automatically when you create a tag. They're really just using the git archive command in the background.

I suggest you also manually designate the tag as a release. You can do this in one step, creating the tag and designating the tag as a release, using the GitHub GUI. Just go to https://github.com/cslarsen/jp2a/releases and click "Draft a new release" in the upper right. (See https://help.github.com/articles/creating-releases/)

Once the release is created you can upload a release archive tarball with autoreconf already having been run, or just leave that to downstream to handle for you.

[sebix]

A tarball is created and linked for all tags automatically. You can upload additional files (like signature and similar).

So just tag the release in git, push it, make a release from the tag on the website and put in the changelog as description. Or create the tag on the website too if your prefer it.

[cslarsen]

I'm aware that tags automatically create tarballs. I'm talking about a dist tarball, and I don't know how package manager usually do those. The usual approach is to make a dist release which comes with a configure script and so on. I guess that's what I need to do, which means I probably need a release branch and then I can tag those.

[ilovezfs]

Thanks @cslarsen :)

[ilovezfs]

@cslarsen did you have a chance to create a release tarball?

[mohd-akram]

A new release would be very much appreciated, even if just a tag.

[ryandesign]

We at MacPorts are also still waiting for a new working release or at least a git tag of the working 1.0.6 version.

[cslarsen]

Ok guys, I seriously need help with this 😆 I can at least tag 1.0.6, but which commit ID do you want? By the way, with this I'm not intending to generate the config scripts or anything at all. How problematic is that (I know it usually is, but it's been like so insanely long ago I touched any of this, I'd have to spend quite a lot of time getting up to speed). Please help me out and we can work it out together.

[ryandesign]

Ok guys, I seriously need help with this 😆 I can at least tag 1.0.6, but which commit ID do you want?

Whichever commit was used to produce to the 1.0.6 download files located here:

https://sourceforge.net/projects/jp2a/files/jp2a/1.0.6/

As far as I can tell, the correct commit is 46a22d6, because that corresponds to Subversion r460, which is the largest revision number mentioned in the $Id$ lines.

(Now that I've realized those 1.0.6 download files are there, I should just use those for MacPorts.)

By the way, with this I'm not intending to generate the config scripts or anything at all.

The 1.0.6 download files on SourceForge already have generated configure scripts, so that's fine. You could even attach copies of those 1.0.6 files from SourceForge to the GitHub release object for the 1.0.6 git tag that you'll create here. Or you could include a link directing users to the existing files on SourceForge.

[IllyaMoskvin]

Confirming that this is still an issue. Homebrew now installs v1.0.7 by default.

It might be best to just tag v1.0.8. I don't know how package managers will handle you tagging an old commit with v1.0.6, since the broken v1.0.7 is technically newer than 46a22d6.

I'd recommend either tagging the current HEAD (61d205f) or a729580 with v1.0.8, assuming that they function as intended.

As a temporary work-around, we've been doing the following:

brew unlink jp2a
brew install https://raw.githubusercontent.com/Homebrew/homebrew-core/31b5579ccb72ccf24e9d01962e422aece563cff5/Formula/jp2a.rb

...this isn't ideal, since we have to steer users away from doing this:

brew install jp2a

...as this now installs the broken v1.0.7.

[IllyaMoskvin]

Sorry to bother, but can we get an update on this issue?

As mentioned, the current version in Homebrew is still broken. We are working on distributing a project that depends on jp2a via Homebrew (aic-bash), and I'm not sure that I can specify the jp2a package as a dependency, since the only version in Homebrew does not work.