Version 2024 01 24

[drwells]

Here we go. I'll tag the merge commit from this PR as release 2024.1.24.

[boyceg]

Can we tag it 2024.01.24? Or are we not going to release between October and December?

[drwells]

The version numbers are defined in the header as integer constants, not strings, so I don't think we need to add the extra zero. Why wouldn't we be able to tag 2024.10.24 or some equivalent later this year?

[boyceg]

Sorry, it was a bad joke.

The reason to add the extra zero is just so that when you sort, you would be guaranteed to get 2024.01.24 showing up before (e.g.) 2024.11.01.

[drwells]

oh, it seemed like a good question to me!

so right now in IBAMR we have

#define IBTK_VERSION_GTE(major, minor, subminor)                                          \
    ((IBTK_VERSION_MAJOR * 10000 + IBTK_VERSION_MINOR * 100 + IBTK_VERSION_SUBMINOR) >= \
     (major)*10000 + (minor)*100 + (subminor))

and, if we need it, we would do the same thing with SAMRAI versions. That's going to work the same with 01 and 1.

[drwells]

If you look at the tags for IBAMR they are in chronological order - i.e., IBAMR-0.10 comes before IBAMR-0.9 so I think this schema will show up in the correct order as well.

[boyceg]

I am thinking more along the lines of “sorting files in a directory” — like if you were to download the tagged release, it seems like it would be better for it to be named something like IBSAMRAI2-20240124.tar.gz or IBSAMRAI2-2024.01.24.tar.gz.

[drwells]

sure, why not

[drwells]

Any other comments? If not, lets merge and tag a release.