Create v3.0.0 official public release

[hjmjohnson]

@afni-rickr Now that we have a pretty good handle on all the compiler settings, a nightly dashbaord, a reworked & modernized cmake, and other improvements, I'd like to work on creating a v3.0.0 release of the nifti_clib repository.

Could you assist with this process?

• @hjmjohnson Convert README to README.md, and add links to the https://my.cdash.org/index.php?project=nifti_clib
• @hjmjohnson Add links to https://nifti-imaging.github.io/ as the main web page.
• @hjmjohnson Remove the dead repos from NIFTI-Imaging now that we have agreed to work with the separate repos rather than one combined repo.
• @hjmjohnson Add badges to readme regarding builds of the master and release branches
• @afni-rickr Make a release notes of code changes from 2011-2018 created from the afni tree (just paste them as part of this message).
• @afni-rickr Expand this list of to-do items as you see fit.
• @afni-rickr Determine fate of fslio. Should we remove it from the repository now and point to the FSL source download?
• @hjmjohnson Fix final scan-build warnings of leaked memory.
• @fissell Anything you want to have done before a 3.0.0 release? Just add comments here
• @leej3 Anything you want to have done before a 3.0.0 release? Just add comments here

[leej3]

Nothing from me on this. Thanks. I'll work on getting conda packaging and integration with AFNI going in the New Year.

[hjmjohnson]

@afni-rickr I am in agreement. A v3.0.0 release should be done.

I would have liked to have #33 with a higher coverage before the release, but it seems that tasks is not going to get the love it needs in the near future.

Let me know when the release is completed. I'll integrate into ITK, and close this issue at the same time.

Hans

Hi Hans,

We have been a little quiet on the NIFTI front lately. So maybe we should go ahead and turn what is there into an "official" v3.0.0 release, what do you think?

https://github.com/NIFTI-Imaging/nifti_clib/releases

There are certainly a few instructional updates that could be made, but it would be nice to make something official.

How does that seem?

Thanks,

-- rick

[yarikoptic]

@afni-rickr I am in agreement. A v3.0.0 release should be done.

woohoo! Any ETA on it?

[yarikoptic]

and, I could be completely wrong, but if there is no API breakage and library SOMAJOR could just stay 2 then, why not to release it as e.g. 2.SOMETHING.0 instead of jumping to 3? or was there a breakage?

[gdevenyi]

Should definitely follow https://semver.org/ standards for naming.

[afni-rickr]

Agreed. It seems a good suggestion to add an so file for the NIFTI-2 standard version of libniftiio (called libnifti2io? a subtle difference). Then it would seem likely that libniftiio and libznz would only need minor version updates (I need to check on that).
So as neurodebian currently has libnifti2 with 2.0.0 versions of the NIFTI-1 library (e.g. /usr/lib/libniftiio.so.2.0.0), this could possibly just be a version (and file) bump for that, to libniftiio.so.2.1.0. And then it could also package libnifti2io.so.2.0.0 (or should they all go to 2.1.0 together?).

It would be great having both niftio's there, so developers could link against either, without breaking anyone's current software.

Does that work @yarikoptic?

[yarikoptic]

So as neurodebian currently has libnifti2 with 2.0.0 versions of the NIFTI-1 library (e.g. /usr/lib/libniftiio.so.2.0.0), this could possibly just be a version (and file) bump for that, to libniftiio.so.2.1.0. And then it could also package libnifti2io.so.2.0.0 (or should they all go to 2.1.0 together?).

yes, that sounds good. Would those be built from the same version of nifti_clib (just making sure)? I guess they could both be 2.1.0 for consistency at least to start with. and libniftiio.so.2.1.0 would be backward compatible with libniftiio.so.2.0.0 (making sure again)?
But then may be the release version could also be 2.1.0 (since it never was released with this version anyways)

[afni-rickr]

Yes, using a consistent 2.1.0 would make sense. Yes, they would all come from the same version of the nifti_clib source tree, with libniftiio.so.2.1.0 being backward compatible (I still need to verify that, as well as libznz).

[afni-rickr]

Indeed, the NIFTI-1 library looks fine, being backwards compatible, but there is a change to znzlib that is not quite backward compatible (znzseek/tell now return znz_off_t, typically off_t, instead of long). So when using the updated libniftiio, one should also use the updated libznz. Though I am not sure why those are separate libraries.

[leej3]

Hoping for a release soon, I’m wondering do we have a consensus on package version, so versions?
It would be nice to have a clear versioning strategy moving forward (I think we’re all agreed on semantic versioning). There is some variety in pre-existing releases made:
https://packages.debian.org/stretch/nifti-bin
https://rpmfind.net/linux/rpm2html/search.php?query=libznz.so.2

Nifti libraries (as currently defined in the cmake build):
libniftiio.so
libnifti2.so

These correspond to libraries that provide IO for the NIFTI-1 and NIFTI-2 file formats respectively. Should we suggest package names nifti2clib and nifti2bin (and package both libraries) or leave that to distribution maintainers to decide?

Talking with @afni-rickr, it seems the only breakage in backwards compatibility is for znz: it now has more complete support for larger file sizes. This does not break backwards compatibility for the libnifti2.so interface. What version should this cause libznz to jump to? And does force the release major version to increment to 3.0 as the issue title suggests or can we get away with 2.1? Should this znzlib.o be just included in the nifti2 IO library to prevent such a problem in future (i.e., those znz functions would be part of the library (in the .so file), and so the library would no longer depend on libznz.

[hjmjohnson]

@leej3 I will leave the versioning decision in your capable hands. I have no problem with increasing it.

[leej3]

@hjmjohnson, @afni-rickr how do you feel about making a release now?

[hjmjohnson]

Pretty good. Go for it!

[leej3]

Great. @afni-rickr ok-d it too. Done. Working through homebrew, Conda, and Debian packages now.