cat 12.8.2 standalone release

[christiangaser]

cat 12.8.2 standalone release

[ChristianGaser]

The new standalone version 12.8.2 for Linux was just uploaded.

[octomike]

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 🙈

[ChristianGaser]

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]

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

[ChristianGaser]

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]

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]

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?

[ChristianGaser]

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]

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