Any objection to creating a release for CRAM 3.1 inclusion

[nh13]

I hope don't step on any toes, we do need a release for CRAM 3.1 support (see #1739 and #1736).

Any objections with me making a release. I'll leave this open for two weeks, and no objections, I'll make a release.

[cmnbroad]

@nh13 There is already a release (4.3.0) that supports reading CRAM 3.1 (I know it doesn't LOOK like its released, but it is - see broadinstitute/picard#2028 (comment)). As for writing 3.1, thats more than just a matter of a release, since there is still some work left to be done. Unclear how that will get done but I think there are discussions under way.

[yfarjoun]

Thanks Chris, we got confused at the last hts-spec meeting.. good to know that reading works!

…

On Sun, Feb 15, 2026 at 5:18 PM Chris Norman ***@***.***> wrote: *cmnbroad* left a comment (samtools/htsjdk#1755) <#1755 (comment)> @nh13 <https://github.com/nh13> There is already a release (4.3.0) that supports reading CRAM 3.1 (I know it doesn't LOOK like its released, but it is - see broadinstitute/picard#2028 (comment) <broadinstitute/picard#2028 (comment)>). As for writing 3.1, thats more than just a matter of a release, since there is still some work left to be done. Unclear how that will get done but I think there are discussions under way. — Reply to this email directly, view it on GitHub <#1755 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAU6JUSF2FJKIN2PGTKW2ZL4MDWFBAVCNFSM6AAAAACVBU4XA6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTSMBVGI4DKNBVGE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[jkbonfield]

@nh13 There is already a release (4.3.0) that supports reading CRAM 3.1 (I know it doesn't LOOK like its released, but it is - see broadinstitute/picard#2028 (comment)). As for writing 3.1, thats more than just a matter of a release, since there is still some work left to be done. Unclear how that will get done but I think there are discussions under way.

The problem is that it's not released - it's tagged. In github work flows that's a very different thing.

Similarly, people don't just want htsjdk, they want the tool chains that go with it. The latest picard release in github (3.4.0) uses htsjdk 4.2.0. There isn't even a new tag there.

A lot of distributions or prebuilt binaries from e.g. conda or biocontainers automatically monitor github releases to know when to rebuild a new version. Tagging alone is insufficient to trigger this. Take a look at bioconda's picard as an example. Picard v3.4.0 was released April 13th 2025. Bioconda updated its recipe the same day:

bioconda/bioconda-recipes@29acb4e

By adding a release to htsjdk (and correspondingly picard), the code will automatically start getting utilised. Yes it's possible to work around it manually, but it drastically limits adoption.