search

ChristianGaser / cat12

Computational Anatomy Toolbox for SPM12
https://neuro-jena.github.io/cat
GNU General Public License v2.0
32 stars 5 forks source link

cat 12.8.2 standalone release #5

Closed octomike closed 1 year ago

octomike commented 1 year ago

Hello!

I was very happy to see that a lot of work went into a standalone version of cat12, that is so much appreciated. Thank you!

In combination with https://github.com/jhuguetn/cat12-docker it's now super easy to run cat12 on our cluster and automatically follow the releases of @jhuguetn to auto-download containers. They are using manual releases based on the content of the download folder http://www.neuro.uni-jena.de/cat12/ however. It seems that there is no versioned release for 12.8.2, just yet. Maybe it's in latest?

May I request a release for CAT12.8.2_r2159_R2017b_MCR_Linux.zip so we get to run the latest code with our container workflow, please? :)

ChristianGaser commented 1 year ago

The new standalone version 12.8.2 for Linux was just uploaded.

octomike commented 1 year ago

Awesome! But I need to nitpick a little..

The bots would be very happy about a consistent release name, as in CATX.Y.Z_rAAAA_R2017b_MCR_Linux.zip :see_no_evil:

ChristianGaser commented 1 year ago

My intention by not using the release number anymore was to make the process of creating the standalone version a bit easier for me and to only provide the version number (i.e. 12.8.2) in future. However, I see the point and could change that if you wish.

Christian

Am 23.01.2023 um 14:18 schrieb Michael @.***>:

Awesome! But I need to nitpick a little.. The bots would be very happy about a consistent release name, as in CATX.Y.Z_rAAAA_R2017b_MCR_Linux.zip 🙈 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you modified the open/close state.Message ID: @.***>

octomike commented 1 year ago

I unterstand and I don't want to create unnecessary hassle with this request.

Right now it seems there are intermediate releases before you put a new 12.x.y out there. I guess it boils down to these questions:

ChristianGaser commented 1 year ago

The version numbers indicate that preprocessing will be compatible, but the different releases sometimes add functionality and/or remove bugs. My idea with only defining the version in the standalone file was that I can easily update if necessary, but don't have to keep all single releases (that are large).

Am 24.01.2023 um 09:41 schrieb Michael @.***>:

I unterstand and I don't want to create unnecessary hassle with this request. Right now it seems there are intermediate releases before you put a new 12.x.y out there. I guess it boils down to these questions: • are we going to miss important changes if we only track those major releases? • can we assume that for a given x,y all 12.x.y versions are somewhat "comparable"/interchangable • if not, we could, as a fallback, download the repos, extract the rolling version and tag the containers manually — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you modified the open/close state.Message ID: @.***>

jhuguetn commented 1 year ago

Hi both,

Ideally, I would like having the binaries of a given version/revision (or release?) untouched so if e.g. I want to re-run something with an specific version I can do it as I did 2 years ago using Docker.
Replacing existing binaries on a regular basis for updated versions of themselves might be well controlled apparently but could very easily bring up inconsistencies in terms of scientific reproducibility. I have seen that, I have been there.

That being said, and understanding @ChristianGaser's point of view, I would suggest having few stable releases (with its binaries left untouched as is now) pinned to each CAT version and then additionally include a cutting-edge release which could be updated/replaced regularly as your idea was. Would that be ok?

Just giving my opinion, at the end is your software and up to you to choose how to release it. We will try to adapt to any changes to provide a Docker-based alternative for running CAT.

octomike commented 1 year ago

I would suggest having few stable releases (with its binaries left untouched as is now) pinned to each CAT version and then additionally include a cutting-edge release which could be updated/replaced regularly as your idea was. Would that be ok?

Having only real releases as containers sounds fine to me.

Just to make sure: a version called 12.8.x would then always refer to the first version that was released with this prefix, right? For example, right now there are:

on the mirror. So when we would had automatically pulled and built CAT 12.8.1 it would have been r1980 and stayed that way until 12.8.2 was released, correct?

Would this be in sync with the release cycle of the cat12 toolbox (on github or on neuro-jena.github.io)? I.e. will our users be confused when there is different code for 12.8.x in the container and in their toolbox?

ChristianGaser commented 1 year ago

It is Okay for me to change back to the old naming system with the release number included in the name. However, for the compilation of the standalone versions there is always a bit more effort necessary because I do this on a virtual machine that provides Ubuntu 17.10 and Windows 10. I have to use the older Ubuntu version to be compatible to older Linux systems (glibc issues). Thus, I will provide the standalone versions less often and only if major changes occur. I hope this is fine with you.

Am 24.01.2023 um 17:30 schrieb Michael @.***>:

I would suggest having few stable releases (with its binaries left untouched as is now) pinned to each CAT version and then additionally include a cutting-edge release which could be updated/replaced regularly as your idea was. Would that be ok? Having only real releases as containers sounds fine to me. Just to make sure: a version called 12.8.x would then always refer to the first version that was released with this prefix, right? For example, right now there are: • CAT12.8.1_r1980_R2017b_MCR_Linux.zip • CAT12.8.1_r1991_R2017b_MCR_Linux.zip • CAT12.8.1_r2040_R2017b_MCR_Linux.zip • CAT12.8.1_r2042_R2017b_MCR_Linux.zip on the mirror. So when we would had automatically pulled and built CAT 12.8.1 it would have been r1980 and stayed that way until 12.8.2 was released, correct? Would this be in sync with the release cycle of the cat12 toolbox (on github or on neuro-jena.github.io)? I.e. will our users be confused when there is different code for 12.8.x in the container and in their toolbox? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

jhuguetn commented 1 year ago

That sounds good to me, thank you so much @ChristianGaser.