:bug: Wrong version generated by gen_version.py

[jamal919]

Since we are currently in v5.10.0 tag version of schism, and sha:9cdc9bb as of writing, the expected output of the gen_version.py is -

SCHISM version: v5.10.0mod
GIT commit  9cdc9bb

However, the actual output is -

SCHISM version:  v5.9.0mod
GIT commit       9cdc9bb

A possible solution would be to not use the git describe, and use the list of tag directly to extract the last tag. Git describe is not behaving the expected way. But its gets convoluted, as stofs3d-atl.v1.1.0 is in the list as a different version numbering.

git tag -l outputs the alphabetical order

r5255
stofs3d-atl.v1.1.0
v5.10.0
v5.8.0
v5.9.0

if sorted by tagger date git tag --sort=taggerdate, the output is

r5255
v5.8.0
v5.9.0
v5.10.0
stofs3d-atl.v1.1.0

For now a probable fix is --sort="version:refname" as in git tag -l --sort="version:refname"| grep v* | tail -n 1 to get the last 'v' tag, and git rev-parse --short HEAD to get the sha. As of writing the output of the commands are following -

~ git tag -l --sort="version:refname"| grep v* | tail -n 1
v5.10.0

~ git rev-parse --short HEAD
9cdc9bb

Thanks.

[water-e]

I am able to reproduce the behavior on my system.

The proposed fix isn't safe. For instance, you can check out the code and type 'git checkout v5.8.0' and git tag will show v5.10.0 as the maximum "v" version. It will also report v5.10.0 on the trunk as well in between versions. In short, the "latest tag" can be different from what you want. If we are disciplined about release branches, though, it will not be.

v5.10.0 was originally built atop a release branch but it has been deleted and that is a misunderstanding about best practices. In fact, we don't really have a reason for calling a tag v5.10.0 at all if we have no v5.10 release branch to continue the lineage and create a v5.10.1 bug fix without mixing in new development. I believe that maintaining the release branch will make it simpler to trace closest reachable tags. Obviously, this works sometimes -- v5.9 and v5.8.0 don't have this issue and it is probably the confounding tag you mentioned that causes the problem.

This is a bit of an unfortunate situation, and I think the best solution is fix it with version control. Fortunately it is pretty easy to go back into the past. I am pretty sure we can either go back and recreate the v5.10 branch and v5.10.0 tag, deleting it and replacing it (the code will be identical) or we could move on to v5.11.0 if the code isn't in upheaval.

[hot007]

I notice the output of make still tends to be things like pschism_5.8.0_HYDRO_VL instead of 5.x where x is derived from the checkout tag, be good to sort that at the same time :)

[water-e]

Claire, OK we can include that. You are using GNU make? It might not matter ... I suppose if this is broken one place it is broken several places. Joseph has pointed out by email that v5.10 branch is still in there -- I was looking at a truncated list. But we still need to figure out why git describe doesn't work. I'll look at it in git kraken which has good diagrams that might reveal something.

[water-e]

OK, I see two things here that might be worth looking into.

First, it appears that v5.10.0 and stofs3d-atl.v.1.1.0 tags both point to the same thing. This is something that is known to confuse git describe.

The second issue is that the ordering is weird. I'm less confident, so forgive me if I'm wrong, but it seems that the release branch v5.10 is derived from the tag v5.10.0. If so, that would be the wrong way to go about things. You want the official release branch v5.10 before you start tagging specific versions like v5.10.0. You could always tag something pre-v5.10 if you want to tag the state before the release branch.

I think we should address both these issues. If we don't care about stofs3d-atl.v.1.1.0 removing it is probably one-stop shopping for fixing the first problem. I doubt this is the case though -- it seems to have some meaning to NOAA. Anyhow, I think we may see the double tagging get revenge again later -- as long as we are doing this double tag there will be some risk that folks will forget that the order matters.

Dealing with the ambiguous tag doesn't address the second problem of things being out of order. if I'm reading the diagrams correctly the release branch v5.10 at commit 53fbf7 has the tag v5.10.0 as its ancestor. To be specific the lineage from the release branch (53fbf7) backward is 3cf45d, 4ddd680, fd48b3 and finally 1e0247 which is the target of the v5.10/stofs tags . All these intermediate commits have messages involving documentation and affect yaml files, so I assume making a few changes in where the tag is pointing to after the branch would only improve things and would not impact the state of the numerical code.

One way to fix this in GitHub this:

1. Delete both the stofs3d and v5.10.0 tags.
2. Re-create the stofs tag after v5.10 branch.
3. Make a trivial commit
4. Add the v5.10.0 tag.

The trivial commit is there to make the two tags non-duplicate. It may be that it is enough that the v5.10.0 is the most recent tag, so a slight variant would be to try skipping the trivial commit and just reordering the commits as shown.

And heck, if just changing the order is going to work then we could probably do something that doesn't change the state of 5.10.0 at all even down to the documentation:

1. delete the tags and the release branch
2. reintroduce all three where the tags are now, in the order: v5.10, stofs3d-atl.v1.1.0, v5.10.0. That would leave Jamal's documentation changes after that commit stranded. We could add a v5.10.1 at the end of the line (where v5.10 is now) to pick up the extra documentation. This kind of sounds like overkill, though. I think most users would be happy if the v5.10.0 code didn't call itself 5.9.

I'm happy to try any of these. I'm fine implementing it, but I'm awaiting your feedback. I think we should wait until this is straightened out before going to Claire's addition.

[jamal919]

Thanks @water-e for debugging it. If it fixes, that will be of great help. BTW, I fully agree with your conclusion that on master branch the temporary fix I proposed is not very robust. However, it should work in individual release branch (tag and branch). In any case, the most important thing is probably to get a consistent version numbering.

A related topic to gen_version.py script - would it be worthwhile to replace gen_version.py with bash/shell script to reduce the dependency on python for compilation?

I think we should address both these issues. If we don't care about stofs3d-atl.v.1.1.0 removing it is probably one-stop shopping for fixing the first problem. I doubt this is the case though -- it seems to have some meaning to NOAA. Anyhow, I think we may see the double tagging get revenge again later -- as long as we are doing this double tag there will be some risk that folks will forget that the order matters.

Pardon me if I am getting on the wrong foot, but tagging production code of NOAA and standard schism release in one single repository will probably only increase confusion (for both NOAA side and other user community side). It appears to me that a good strategy for NOAA would probably be to fork the schism-dev/schism to NOAA-XYZ*/schism, and tag/branch as necessary for production (with periodic syncing with the upstream)?

*XYZ being the associated division of NOAA, at least that seems to be the naming scheme of the github account of various divisions

[josephzhang8]

Thanks, Eli for the nice detective work! You are right that stofs* tag is requested by NOAA. I don't recall the deletion of v5.10 but you may be right that I created v5.10.0 first. I cannot remember now.

I'd suggest we do this the correct way for the next tag release, given that we are in the middle of very active project usage of the tags, to avoid further confusion. Thx.

-Joseph

Y. Joseph Zhang Web: schism.wiki Office: 804 684 7466

From: water-e @.> Sent: Tuesday, September 13, 2022 2:06 AM To: schism-dev/schism @.> Cc: Subscribed @.***> Subject: Re: [schism-dev/schism] :bug: Wrong version generated by gen_version.py (Issue #84)

[EXTERNAL to VIMS received message]

OK, I see two things here that might be worth looking into.

First, it appears that v5.10.0 and stofs3d-atl.v.1.1.0 tags both point to the same thing. This is something that is known to confuse git describe.

The second issue is that the ordering is weird. I'm less confident, so forgive me if I'm wrong, but it seems that the release branch v5.10 is derived from the tag v5.10.0. If so, that would be the wrong way to go about things. You want the official release branch v5.10 before you start tagging specific versions like v5.10.0. You could always tag something pre-v5.10 if you want to tag the state before the release branch.

I think we should address both these issues. If we don't care about stofs3d-atl.v.1.1.0 removing it is probably one-stop shopping for fixing the first problem. I doubt this is the case though -- it seems to have some meaning to NOAA. Anyhow, I think we may see it get revenge again later -- as long as we are doing this there will be some risk that folks will forget about it.

Dealing with the ambiguous tag doesn't address the second problem of things being out of order. if I'm reading the diagrams correctly the release branch v5.10 at commit 53fbf7 has the tag v5.10.0 as its ancestor. To be specific the lineage from the release branch (53fbf7) backward is 3cf45d, 4ddd680, fd48b3 and finally 1e0247 which is the target of the v5.10/stofs tags . All these intermediate commits have messages involving documentation and affect yaml files, so I assume making a few changes in where the tag is would only improve things and would be fairly safe from the point of view of the numerical code.

One way to fix this in GitHub this:

1. Delete both the stofs3d and v5.10.0 tags.
2. Re-create the stofs tag after v5.10 branch.
3. Make a trivial commit
4. Add the v5.10.0 tag.

The trivial commit is there to make the two tags non-duplicate. A slight variant would be to try skipping the trivial commit and hoping that switching order (so that v5.10.0 is after the other one) does the trick.

I'm happy to try either one if no one has any objections or better idea. I think we should wait until this is straightened out before going to Claire's issue.

- Reply to this email directly, view it on GitHubhttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fschism-dev%2Fschism%2Fissues%2F84%23issuecomment-1244941528&data=05%7C01%7Cyjzhang%40vims.edu%7Cd89ee339c5ea4a2f614d08da954e0565%7C8cbcddd9588d4e3b9c1e2367dbdf1740%7C0%7C0%7C637986459591217801%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=mWG9A2uMcyGrYX7DZngDQ5fCr%2B6baP3PWQGvWLGV4RY%3D&reserved=0, or unsubscribehttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAFBKNZ2HX4SYD7SPP4VWHO3V6AKUFANCNFSM6AAAAAAQKFRKR4&data=05%7C01%7Cyjzhang%40vims.edu%7Cd89ee339c5ea4a2f614d08da954e0565%7C8cbcddd9588d4e3b9c1e2367dbdf1740%7C0%7C0%7C637986459591217801%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=DJKse1YB2%2FgJ1PU7yKVmv4qACpB2rhf34NeNnyTG5Ck%3D&reserved=0. You are receiving this because you are subscribed to this thread.Message ID: @.**@.>>

[water-e]

Jamal, We'll get the consistency one way or another. I don't think 'git tag' is that -- it would change the number assigned in a stable branch as things are added. The NOAA idea of retagging is awkward, but I blame git describe and the inherent difficulty of getting the right info as much as anything. We'll see how the NOAA folks and Joseph respond.

As to the suggestion about phasing it out this would be a community decision. I vote no with both hands and feet. I (and several others) joined in a discussion about switching python on some of the scripts.

I find python much more self-documenting than bash and so did a few others and I've always found python available, albeit out of date, even on esoteric machines (defunct Cray etc). Also this script is meant to negotiate situations like where there is no git or the user has their own system and that isn't going to be a one-line bash script. That is probably not functioning right at the moment (Claire's issue) but it is a small matter to repair it. So .... is this really a concrete problem or a musing?

There is another cost to me. In our group, we maintain a windows compilation (5.10 due soon) that is reasonably performant and that we use for classes. It seems silly to have cmake plumbed out all the way to this point and then use bash. We could possibly use raw cmake for this, but gen_version as a prerequisite would stay for windows and then what would we have achieved? It is also a fair amount of logic for cmake.

gen_version.py should work on 2.x or 3.x and if it turns out that isn't true I'll fix it so it does. If folks are working widely on machines that don't have python please let me know.

[josephzhang8]

The NOAA story is a little more complex... the do have a fork but they want to quality control with the community git tags.

-Joseph

Y. Joseph Zhang Web: schism.wiki Office: 804 684 7466

From: Jamal Uddin Khan @.> Sent: Tuesday, September 13, 2022 4:20 AM To: schism-dev/schism @.> Cc: Subscribed @.***> Subject: Re: [schism-dev/schism] :bug: Wrong version generated by gen_version.py (Issue #84)

[EXTERNAL to VIMS received message]

Thanks @water-ehttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fwater-e&data=05%7C01%7Cyjzhang%40vims.edu%7C186fa9c285b5413ad91008da9560b6d8%7C8cbcddd9588d4e3b9c1e2367dbdf1740%7C0%7C0%7C637986539881511329%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=WoBgAutwzaITpbRCmtBJmQARN0u5mRNjzyB%2F5LoptF0%3D&reserved=0 for debugging it. If it fixes, that will be of great help. BTW, I fully agree with your conclusion that on master branch the temporary fix I proposed is not very robust. However, it should work in individual release branch (tag and branch). In any case, the most important thing is probably to get a consistent version numbering.

A related topic to gen_version.py script - would it be worthwhile to replace gen_version.py with bash/shell script to reduce the dependency on python for compilation?

I think we should address both these issues. If we don't care about stofs3d-atl.v.1.1.0 removing it is probably one-stop shopping for fixing the first problem. I doubt this is the case though -- it seems to have some meaning to NOAA. Anyhow, I think we may see the double tagging get revenge again later -- as long as we are doing this double tag there will be some risk that folks will forget that the order matters.

Pardon me if I am getting on the wrong foot, but tagging production code of NOAA and standard schism release in one single branch will probably only increase confusion (for both NOAA side and other user community side). It appears to me that a good strategy for NOAA would probably be to fork the schism-dev/schism to NOAA-XYZ*/schism, and tag/branch as necessary for production?

*XYZ being the associated division of NOAA, at least that seems to be the naming scheme of the github account of various divisions

- Reply to this email directly, view it on GitHubhttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fschism-dev%2Fschism%2Fissues%2F84%23issuecomment-1245063003&data=05%7C01%7Cyjzhang%40vims.edu%7C186fa9c285b5413ad91008da9560b6d8%7C8cbcddd9588d4e3b9c1e2367dbdf1740%7C0%7C0%7C637986539881511329%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=FGFK%2FeAw93fl7DNvTGkgJIJAwiF2uN59n5pqZzukjOs%3D&reserved=0, or unsubscribehttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAFBKNZZB7VV2RBDCRTR4YJTV6A2KBANCNFSM6AAAAAAQKFRKR4&data=05%7C01%7Cyjzhang%40vims.edu%7C186fa9c285b5413ad91008da9560b6d8%7C8cbcddd9588d4e3b9c1e2367dbdf1740%7C0%7C0%7C637986539881511329%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Y6ZgWM9YkxmbxIg7o5QTMLTY32gVljYchcDmwukWI74%3D&reserved=0. You are receiving this because you are subscribed to this thread.Message ID: @.**@.>>

[jamal919]

We'll get the consistency one way or another. I don't think 'git tag' is that -- it would change the number assigned in a stable branch as things are added. The NOAA idea of retagging is awkward, but I blame git describe and the inherent difficulty of getting the right info as much as anything. We'll see how the NOAA folks and Joseph respond.

I agree, git tag is not a solution, but a band-aid :)

As to the suggestion about phasing it out this would be a community decision. I vote no with both hands and feet. I (and several others) joined in a discussion about switching python on some of the scripts.

I find python much more self-documenting than bash and so did a few others and I've always found python available, albeit out of date, even on esoteric machines (defunct Cray etc). Also this script is meant to negotiate situations like where there is no git or the user has their own system and that isn't going to be a one-line bash script. That is probably not functioning right at the moment (Claire's issue) but it is a small matter to repair it. So .... is this really a concrete problem or a musing?

There is another cost to me. In our group, we maintain a windows compilation (5.10 due soon) that is reasonably performant and that we use for classes. It seems silly to have cmake plumbed out all the way to this point and then use bash. We could possibly use raw cmake for this, but gen_version as a prerequisite would stay for windows and then what would we have achieved? It is also a fair amount of logic for cmake.

gen_version.py should work on 2.x or 3.x and if it turns out that isn't true I'll fix it so it does. If folks are working widely on machines that don't have python please let me know.

Thanks for the long reasoning :). To begin, my vote is also for python and I was not suggesting for a change. Personally, I also do everything through python. It was rather just a curious question, and the root of it lies to a time when I was browsing for ways to extract the version number for a personal project. I ended up using python, BTW. Like everything there is multiple packages, and I was lazy to write a gen_version.py. But in the searching process, I found that git itself use a bash script - https://github.com/git/git/blob/master/GIT-VERSION-GEN - hence my question. The change of the gen_version script is clearly not worthwhile, however this exchange certainly was.

[water-e]

OK, Joseph I think my solution is going to work. I think it can be deleted if it doesn't. Tags and branches can always be recreated as necessary. Shall I proceed? I think I can do it locally first anyhow.

[josephzhang8]

Sure if you insists. Thx Eli.

-Joseph

Y. Joseph Zhang Web: schism.wiki Office: 804 684 7466

From: water-e @.> Sent: Tuesday, September 13, 2022 12:36 PM To: schism-dev/schism @.> Cc: Y. Joseph Zhang @.>; Comment @.> Subject: Re: [schism-dev/schism] :bug: Wrong version generated by gen_version.py (Issue #84)

[EXTERNAL to VIMS received message]

OK, Joseph I think my solution is going to work. I think it can be deleted if it doesn't. Tags and branches can always be recreated as necessary. Shall I proceed? I think I can do it locally first anyhow.

- Reply to this email directly, view it on GitHubhttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fschism-dev%2Fschism%2Fissues%2F84%23issuecomment-1245665426&data=05%7C01%7Cyjzhang%40vims.edu%7C688fae9a10644d47818408da95a61ad5%7C8cbcddd9588d4e3b9c1e2367dbdf1740%7C0%7C0%7C637986837919076302%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=0n0jU0T41BKjyYTPX0NH6yvdzNbb6Pn8Y%2FfCSHo9ikk%3D&reserved=0, or unsubscribehttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAFBKNZ2ZY7QM546QIVGK463V6CUQTANCNFSM6AAAAAAQKFRKR4&data=05%7C01%7Cyjzhang%40vims.edu%7C688fae9a10644d47818408da95a61ad5%7C8cbcddd9588d4e3b9c1e2367dbdf1740%7C0%7C0%7C637986837919076302%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=uU7G4BbUuJ3RUUVymLbsVORsnILOOzsODzuhCobTvVQ%3D&reserved=0. You are receiving this because you commented.Message ID: @.**@.>>

[water-e]

OK, I just confirmed on my copy that reordering the tags works fine when you check out the v5.10.0 tag and use gen_version.py. I'll push it soon.

Before that, any opinion what we want pschism -v to say when someone builds master? Right now it lists 5.9mod because 5.9 is the last tag in that lineage. That is not accurate for post-5.10 work. I could tag something a ways back in the master lineage after the 5.10 release branch and call it 5.11-master. That will get rid of the 5.9 stuff and I think gen_version will barf and cause pschism -v to say something like "develop-1913sdats" where the latter part is the hash. That is good, yes? We don't really want a semantic version number off random places on master anyhow. Anyone have an opinion?

By the way the release branch v5.10 was probably always timed correctly, I was just misreading the location of the HEAD as the location of the branch point. The only problem was the ordering of the noaa and semantic tags.

[josephzhang8]

Thx Eli. I like the actual hash in master (develop-1913sdats).

-Joseph

Joseph Zhang Office: (804) 684 7466 Web: schism.wiki

From: water-e @.> Sent: Tuesday, September 13, 2022 2:59 PM To: schism-dev/schism @.> Cc: Y. Joseph Zhang @.>; Comment @.> Subject: Re: [schism-dev/schism] :bug: Wrong version generated by gen_version.py (Issue #84)

[EXTERNAL to VIMS received message]

OK, I just confirmed on my copy that reordering the tags works fine when you check out the v5.10.0 tag and use gen_version.py. I'll push it soon.

Before that, any opinion what we want pschism -v to say when someone builds master? Right now it lists 5.9mod because 5.9 is the last tag in that lineage. That is not accurate for post-5.10 work. I could tag something a ways back in the master lineage after the 5.10 release branch and call it 5.11-master. That will get rid of the 5.9 stuff and I think gen_version will barf and cause pschism -v to say something like "develop-1913sdats" where the latter part is the hash. That is good, yes? We don't really want a semantic version number off random places on master anyhow. Anyone have an opinion?

By the way the release branch v5.10 was probably always timed correctly, I was just misreading the location of the HEAD as the location of the branch point. The only problem was the ordering of the noaa and semantic tags.

- Reply to this email directly, view it on GitHubhttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fschism-dev%2Fschism%2Fissues%2F84%23issuecomment-1245837128&data=05%7C01%7Cyjzhang%40vims.edu%7Cb044b74c787b4de2aaf508da95ba1470%7C8cbcddd9588d4e3b9c1e2367dbdf1740%7C0%7C0%7C637986923688679763%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=A8tFtzo2%2FkCJKcoc1gvyyOsU3Z73EkMtKmzBWw%2F8o8U%3D&reserved=0, or unsubscribehttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAFBKNZ7VYKS7IU3MR62ZQH3V6DFI5ANCNFSM6AAAAAAQKFRKR4&data=05%7C01%7Cyjzhang%40vims.edu%7Cb044b74c787b4de2aaf508da95ba1470%7C8cbcddd9588d4e3b9c1e2367dbdf1740%7C0%7C0%7C637986923688679763%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=bsxVHH71S8CaM6DwbuC9vDV6iGa0Ul941mGyd49cG4E%3D&reserved=0. You are receiving this because you commented.Message ID: @.**@.>>

[josephzhang8]

I also suggest you only redo stofs* tag, since the sequence of 5.10 and 5.10.0 is correct.

-Joseph

Joseph Zhang Office: (804) 684 7466 Web: schism.wiki

From: water-e @.> Sent: Tuesday, September 13, 2022 2:59 PM To: schism-dev/schism @.> Cc: Y. Joseph Zhang @.>; Comment @.> Subject: Re: [schism-dev/schism] :bug: Wrong version generated by gen_version.py (Issue #84)

[EXTERNAL to VIMS received message]

OK, I just confirmed on my copy that reordering the tags works fine when you check out the v5.10.0 tag and use gen_version.py. I'll push it soon.

Before that, any opinion what we want pschism -v to say when someone builds master? Right now it lists 5.9mod because 5.9 is the last tag in that lineage. That is not accurate for post-5.10 work. I could tag something a ways back in the master lineage after the 5.10 release branch and call it 5.11-master. That will get rid of the 5.9 stuff and I think gen_version will barf and cause pschism -v to say something like "develop-1913sdats" where the latter part is the hash. That is good, yes? We don't really want a semantic version number off random places on master anyhow. Anyone have an opinion?

By the way the release branch v5.10 was probably always timed correctly, I was just misreading the location of the HEAD as the location of the branch point. The only problem was the ordering of the noaa and semantic tags.

- Reply to this email directly, view it on GitHubhttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fschism-dev%2Fschism%2Fissues%2F84%23issuecomment-1245837128&data=05%7C01%7Cyjzhang%40vims.edu%7Cb044b74c787b4de2aaf508da95ba1470%7C8cbcddd9588d4e3b9c1e2367dbdf1740%7C0%7C0%7C637986923688679763%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=A8tFtzo2%2FkCJKcoc1gvyyOsU3Z73EkMtKmzBWw%2F8o8U%3D&reserved=0, or unsubscribehttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAFBKNZ7VYKS7IU3MR62ZQH3V6DFI5ANCNFSM6AAAAAAQKFRKR4&data=05%7C01%7Cyjzhang%40vims.edu%7Cb044b74c787b4de2aaf508da95ba1470%7C8cbcddd9588d4e3b9c1e2367dbdf1740%7C0%7C0%7C637986923688679763%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=bsxVHH71S8CaM6DwbuC9vDV6iGa0Ul941mGyd49cG4E%3D&reserved=0. You are receiving this because you commented.Message ID: @.**@.>>

[water-e]

I can make them point to the same hash they did before, both the same. However in that case I have to delete and recreate 5.10.0 on the newer side of stofs*. Git seems to regard the later creation time as "most recent in lineage" if the the hashes are a tie. Based on a sample of one.

[water-e]

Here is the change. Putting it here because no other real record of it. It works on a round trip for me. @hot007 Can you show me what remains for you after you git fetch and build. I'd need to know what your executable gets named, whether you are cmake or GNU make. Thanks for bearing with me ... this kind of surgery makes me (and I'm sure Joseph) nervous.

# Delete the tags that need swapping  
git tag -d stofs3d-atl.v1.1.0
git push --delete origin stofs3d-atl.v1.1.0 
git tag -d v5.10.0
git push --delete origin v5.10.0
# Retag in NOAA then semantic order, pushing one at a time due to supersticious nature
git tag -a stofs3d-atl.v1.1.0 1e0247 -m"Revised stofs3d-atl.v1.1.0 tag to precede 5.10.0 in hopes this will be read cleanly by git describe and hence fix gen_version.py"
git push origin stofs3d-atl.v1.1.0
git tag -a v5.10.0 1e0247 -m"Revised v5.10.0 after NOAA tag in hopes this will be read cleanly by git describe and hence fix gen_version.py"
git push origin v5.10.0
# Tag master sligthly after 5.10 release branch. gen_version.py won't actually know what to do with this but
# when it breaks it will produce a good hash-based version
git tag -a master-post-5.10 -m"Tagged a commit soon after 5.10 so that it will be found by gen_version.py" 1c62c24a7b5dd7b82ec830445c422e70ab1664dc
git push origin master-post-5.10

[hot007]

Yep okay, I'm using gnu make, my process is

git clone https://github.com/schism-dev/schism.git
cd schism
git checkout tags/v5.10.0
cd mk
# copy in Make.defs.gadi from host
ln -s Make.defs.gadi Make.defs.local
cd ..
module purge
module load intel-compiler/2019.3.199
module load openmpi/3.1.4
module load netcdf/4.7.3
module load python2-as-python
module list
# assumes we are in the directory that contains the source code
# e.g. git clone https://github.com/schism-dev/schism.git -> schism
cd src
make clean
make psc

Output from make includes

 SCHISM version:  v5.10.0
 GIT commit       1e02474

but output executable is, unfortunately, still pschism_5.8.0_HYDRO_VL I've just been manually renaming the executable but this seems like a relevant time to bring it up here! (v5.9 was the same).

[hot007]

See also https://github.com/schism-dev/schism/issues/40

[jamal919]

@hot007 I am suspecting that the executable name is hard defined in the Make.defs.local file, see variable EXEC.

With the compiled executable if you dopschism_5.8.0_HYDRO_VL -v, it will show that the version of the code is v5.10.0

[hot007]

Ah, you are right! We had EXEC= set to include 5.8.0. Is there a way I can change that Make.defs.local file to harvest the version value from git in the Make.defs files? Sorry that's probably a silly question but maybe we need to pass in an env var or something for that? How are other people handling this or do you just not show the version in the executable name and rely on -v? That is also an option of course!

[jamal919]

Is there a way I can change that Make.defs.local file to harvest the version value from git in the Make.defs files? Sorry that's probably a silly question but maybe we need to pass in an env var or something for that?

I guess you can simply change the EXEC value to pschism-`git describe`? That will add the output from git describe to the file name.

FYI:

1. I have not tested it, but should work.
2. File name may become quite long

[water-e]

Depends on what you want the behavior to be when git describe produces something funny. I'm not speaking of the latest problem, more like ... what do you want on master which should probably be the current hash? As before, Jamal, raw calls to git describe neglects the corner cases that occur when there is no tag or the result is funky. Ideally, you want master to produce the hash possibly with 'mod' and you want the user to be able to override.

One option that would be uniform across GNU and CMake would be to tackle these issues as they arise in gen_version.py and then store its output as an environment variable ... and then incorporate that in the executable name in the respective make systems.

It has been a while since I've used the GNU Makefile (I played a role in creating it many years ago but I find it horrifying compared to cmake), so I kind of dread dusting that off, but I can support the python part for the executable (it is just one added line setting os.env). I think we probably haven't seen the end of the corner cases.

[jamal919]

It is indeed clear from all the discussion/examples that using git describe directly is not a good idea. Personally, I always use a static name like pschism-VL_MOD1_MOD2, and check the version from my submission scripts to see if I am indeed running the right executable. But at the same time, for my need I do not change version that often.

If I need to keep a versioned executable in make, for now my solution is rather band-aid approach (similar to above) using git-rev-parse, e.g., EXEC=pschism_`git rev-parse --short HEAD``git diff --quiet || echo '-dirty'`

I like the idea of tackling the version number issue with gen_version.py. May be if gen_version.py script echos the version number, it can be directly used in initialising the EXEC variable? Not sure it is an uniform approach between make and cmake though.

[josephzhang8]

OK looks like we have to recreate 5.10.0 as latest.

-Joseph

Joseph Zhang Office: (804) 684 7466 Web: schism.wiki

From: water-e @.> Sent: Tuesday, September 13, 2022 3:42 PM To: schism-dev/schism @.> Cc: Y. Joseph Zhang @.>; Comment @.> Subject: Re: [schism-dev/schism] :bug: Wrong version generated by gen_version.py (Issue #84)

[EXTERNAL to VIMS received message]

I can make them point to the same hash they did before, both the same. However in that case I have to delete and recreate 5.10.0 on the newer side of stofs*. Git seems to regard the later creation time as "most recent in lineage" if the the hashes are a tie. Based on a sample of one.

- Reply to this email directly, view it on GitHubhttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fschism-dev%2Fschism%2Fissues%2F84%23issuecomment-1245877008&data=05%7C01%7Cyjzhang%40vims.edu%7C9ea959cce9074e75417708da95c00f2e%7C8cbcddd9588d4e3b9c1e2367dbdf1740%7C0%7C0%7C637986949371898971%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=xrHUpaPChbWMIR3mnC75qZFt6T%2BYvD5Pg8ArCBALkKE%3D&reserved=0, or unsubscribehttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAFBKNZYUYNNPSIS7IOVP4V3V6DKJLANCNFSM6AAAAAAQKFRKR4&data=05%7C01%7Cyjzhang%40vims.edu%7C9ea959cce9074e75417708da95c00f2e%7C8cbcddd9588d4e3b9c1e2367dbdf1740%7C0%7C0%7C637986949371898971%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=CL0r5wYawFdFiJ6WOeTVy2n0UJzyLhSOUlKqUj4RW6M%3D&reserved=0. You are receiving this because you commented.Message ID: @.**@.>>

[water-e]

That work for gen_version is already done. We just have to inject the result as an environment variable and people can use it.

---

From: Joseph Zhang @.> Sent: Tuesday, October 11, 2022 1:07 AM To: schism-dev/schism @.> Cc: Ateljevich, @. @.>; Mention @.***> Subject: Re: [schism-dev/schism] :bug: Wrong version generated by gen_version.py (Issue #84)

OK looks like we have to recreate 5.10.0 as latest.

-Joseph

Joseph Zhang Office: (804) 684 7466 Web: schism.wiki

From: water-e @.> Sent: Tuesday, September 13, 2022 3:42 PM To: schism-dev/schism @.> Cc: Y. Joseph Zhang @.>; Comment @.> Subject: Re: [schism-dev/schism] :bug: Wrong version generated by gen_version.py (Issue #84)

[EXTERNAL to VIMS received message]

I can make them point to the same hash they did before, both the same. However in that case I have to delete and recreate 5.10.0 on the newer side of stofs*. Git seems to regard the later creation time as "most recent in lineage" if the the hashes are a tie. Based on a sample of one.

- Reply to this email directly, view it on GitHubhttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fschism-dev%2Fschism%2Fissues%2F84%23issuecomment-1245877008&data=05%7C01%7Cyjzhang%40vims.edu%7C9ea959cce9074e75417708da95c00f2e%7C8cbcddd9588d4e3b9c1e2367dbdf1740%7C0%7C0%7C637986949371898971%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=xrHUpaPChbWMIR3mnC75qZFt6T%2BYvD5Pg8ArCBALkKE%3D&reserved=0, or unsubscribehttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAFBKNZYUYNNPSIS7IOVP4V3V6DKJLANCNFSM6AAAAAAQKFRKR4&data=05%7C01%7Cyjzhang%40vims.edu%7C9ea959cce9074e75417708da95c00f2e%7C8cbcddd9588d4e3b9c1e2367dbdf1740%7C0%7C0%7C637986949371898971%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=CL0r5wYawFdFiJ6WOeTVy2n0UJzyLhSOUlKqUj4RW6M%3D&reserved=0. You are receiving this because you commented.Message ID: @.**@.>>

— Reply to this email directly, view it on GitHubhttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fschism-dev%2Fschism%2Fissues%2F84%23issuecomment-1274268456&data=05%7C01%7C%7Cf935e2fef3544a89de9208daab5f9327%7Cb71d56524b834257afcd7fd177884564%7C0%7C0%7C638010724248829697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2FxRwG0%2BTVo9QFMI8w8C8pNfYi%2BWA%2FtnDv%2F1D9Z19PW4%3D&reserved=0, or unsubscribehttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAG2AJC2G5GOYEI7SGNCJLQDWCUN2JANCNFSM6AAAAAAQKFRKR4&data=05%7C01%7C%7Cf935e2fef3544a89de9208daab5f9327%7Cb71d56524b834257afcd7fd177884564%7C0%7C0%7C638010724248829697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=OMj3wGoQujz8TYIpTz9KtLpd%2FvtgfRqtvhh0oSRY0%2Fw%3D&reserved=0. You are receiving this because you were mentioned.Message ID: @.***>

[brey]

Dear All, may I re-iterate issue #50 and ask for a native __version function that returns the current tag without the git dependency.

[water-e]

In my recollection, this is different from issue #84 which probably should have been resolved. There was unexpected behavior in the way the version was being generated from git information if two tags pointed to the same hash. This was exacerbated by the way versions were being handled, where this was happening on purpose (a NOAA and semantic tag). I think this was resolved.

If I understand correctly, you want a way to print out the version without any use of Git at all. Some years ago we had the ability for the user to manipulate the output of the script that determines version if they wanted something different. This is something I think we could reinstate if there is demand for it.

If we go beyond that, things are more dicey. We'd have to work out a commit hook or assign the responsibility to bump verisons manually. There is also often a chicken-egg issue where the inclusion of version text technically makes the code a new version. For instance if you want a text "5.10.2" to be captured in text that is issued by pschism -v and have it be part of a tag, you have to add that label to the release branch on the commit before it gets tagged. It works OK as long as you are quick and committed, but if you've lived for a while in a world where good housekeeping is critical for versioning you know why I want to avoid it.

Thus, I would oppose any change to this end that makes the automatic versioning harder. For many in the community the git tag is the most primary/reliable thing and the semantic version secondary. I'm not one of them, and I'll go to some trouble to make the semantic versioning standard and reliable. But I want to repair the automata and the correct inference from git tags and hashes, not throw it to the wind. Is giving you the freedom to re-label what comes out of pschism -v on your own good enough?

---

From: George Breyiannis @.> Sent: Sunday, February 26, 2023 10:34 AM To: schism-dev/schism @.> Cc: Ateljevich, @. @.>; Mention @.***> Subject: Re: [schism-dev/schism] :bug: Wrong version generated by gen_version.py (Issue #84)

Dear All, may I re-iterate issue #50https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fschism-dev%2Fschism%2Fissues%2F50&data=05%7C01%7C%7Ce7786197a83741df913c08db18280a09%7Cb71d56524b834257afcd7fd177884564%7C0%7C0%7C638130332484225557%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=QlMvfoPVi0Grk53pV4sW0YZv%2FHk9iKO5nkdPS8yFchI%3D&reserved=0 and ask for a native __version function that returns the current tag without the git dependency.

— Reply to this email directly, view it on GitHubhttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fschism-dev%2Fschism%2Fissues%2F84%23issuecomment-1445430102&data=05%7C01%7C%7Ce7786197a83741df913c08db18280a09%7Cb71d56524b834257afcd7fd177884564%7C0%7C0%7C638130332484225557%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=mShvM01gOWQFQjY3jSSIQpGpY2MBCxrsHcnr%2FFUQfCc%3D&reserved=0, or unsubscribehttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAG2AJCZFV7762MHPIYZ7OOTWZOOZXANCNFSM6AAAAAAQKFRKR4&data=05%7C01%7C%7Ce7786197a83741df913c08db18280a09%7Cb71d56524b834257afcd7fd177884564%7C0%7C0%7C638130332484225557%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=G8exDScxh7VUJRitY3jZuD%2FBEpNcYHN9GYdCpgyJOzM%3D&reserved=0. You are receiving this because you were mentioned.Message ID: @.***>

[brey]

I understand there are two different use cases. I understand the need to have the git versioning working. Maybe this can be automated with something like dunamai?

However the semantic versioning is important for the imminent conda release #13. In addition, the text return of "schism -v" should indeed be the last commit before a release which should coincide with a set of tests working properly and a tag. Currently, there are tags but no releases after 5.9. For distributing the code with coda the git versioning doesn't work.

In fact, I would expect that each release has its own branch for future hot fixes. Also tags are not immutable and shouldn't be used for versioning.

I am open to suggestions on how to best deploy semantic versioning and release management but I think, even if automated, the release should be deliberate and managed while tagging can be more liberal.

Also of note, we are exploring SCHISM as an operational tool. In this context, changing versions is a more elaborate exercise which is not easy to undergo often. The repo management should be able to handle long term support of such processes better.

[josephzhang8]

"Currently, there are tags but no releases after 5.9."

Not sure if I understood this correctly. There are release branches 5.10 - I always push out a release branch before tagging.

Regards,

Joseph Zhang (804)684 7595 (office) SCHISM web: http://ccrm.vims.edu/schism/ From: George Breyiannis @.> Sent: Sunday, March 5, 2023 1:29 PM To: schism-dev/schism @.> Cc: Y. Joseph Zhang @.>; Comment @.> Subject: Re: [schism-dev/schism] :bug: Wrong version generated by gen_version.py (Issue #84)

[EXTERNAL to VIMS received message]

I understand there are two different use cases. I understand the need to have the git versioning working. Maybe this can be automated with something like dunamaihttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmtkennerly%2Fdunamai&data=05%7C01%7Cyjzhang%40vims.edu%7C312d036ae90e402daabe08db1da783a8%7C8cbcddd9588d4e3b9c1e2367dbdf1740%7C0%7C0%7C638136377553883138%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=AUSCOISdGMh%2Bk0NGmxRDxmsH9534uv1tcYbSjeTA%2FWA%3D&reserved=0?

However the semantic versioning is important for the imminent conda release #13https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fschism-dev%2Fschism%2Fissues%2F13&data=05%7C01%7Cyjzhang%40vims.edu%7C312d036ae90e402daabe08db1da783a8%7C8cbcddd9588d4e3b9c1e2367dbdf1740%7C0%7C0%7C638136377553883138%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ullWILFS693aaKCndcaOYCOVizh3CJQMXnskYochxQA%3D&reserved=0. In addition, the text return of "schism -v" should indeed be the last commit before a release which should coincide with a set of tests working properly and a tag. Currently, there are tags but no releases after 5.9. For distributing the code with coda the git versioning doesn't work.

In fact, I would expect that each release has its own branch for future hot fixes. Also tags are not immutable and shouldn't be used for versioning.

I am open to suggestions on how to best deploy semantic versioning and release management but I think, even if automated, the release should be deliberate and managed while tagging can be more liberal.

Also of note, we are exploring SCHISM as an operational tool. In this context, changing versions is a more elaborate exercise which is not easy to undergo often. The repo management should be able to handle long term support of such processes better.

- Reply to this email directly, view it on GitHubhttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fschism-dev%2Fschism%2Fissues%2F84%23issuecomment-1455166943&data=05%7C01%7Cyjzhang%40vims.edu%7C312d036ae90e402daabe08db1da783a8%7C8cbcddd9588d4e3b9c1e2367dbdf1740%7C0%7C0%7C638136377553883138%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ywoGdYE%2B%2FX3uCC537Fv3Y%2BCqNzMIBrAu6o9fBK%2FgntU%3D&reserved=0, or unsubscribehttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAFBKNZYK6EU2TZKWABFRXOTW2TLPNANCNFSM6AAAAAAQKFRKR4&data=05%7C01%7Cyjzhang%40vims.edu%7C312d036ae90e402daabe08db1da783a8%7C8cbcddd9588d4e3b9c1e2367dbdf1740%7C0%7C0%7C638136377553883138%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=UYfCbQUalY52F%2FSfD%2B8H6FcS0ufyGfM3RLXv9VrUOc0%3D&reserved=0. You are receiving this because you commented.Message ID: @.**@.>>

[brey]

You are right the branches are there. I was mislead by the fact that there are no new Github releases (see on the right side of the Github page).

[pmav99]

@josephzhang8 @water-e A bit more context might make our use-case/intentions clearer

1. A conda package installs an executable + necessary libraries. Whoever installs the schism conda package does not need to know anything about compiling schism and/or manipulating the version on runtime. Furthermore, it would not be uncommon for such a user to have multiple versions of the package installed (in different envrionments). All that user expects is that schism -v/--version will print something sensible like make -v/--version, gcc -v/--version and cmake --version do. The output could contain additional information that has to do with the compilation/configuration options, pretty much like gcc -v does, but you could also have a dedicated command for that (similar to docker --info).

2. @gbrey developed pyposeidon which, among other things, facilitates creating and running schism models. In pyposeidon the schism executable is provided as a path. The origin of the executable is irrelevant (compilation vs conda vs module vs whatever). As long as you provide a valid path, things should work. In this context it is important that the schism executable declares its version properly so that pyposeidon can choose the proper pre/post processing steps for the specific version.

[josephzhang8]

Thanks, Panos.

Eli, Carsten understand the issue better than me. The bullet proof way of encoding the module info in the binary is to add the modules in the binary name. OLDIO is an outlier; it was added only to provide backward compatibility and for users who still want to run with 1 CPU.

Regards,

Joseph Zhang (804)684 7595 (office) SCHISM web: http://ccrm.vims.edu/schism/ From: pmav99 @.> Sent: Monday, March 6, 2023 6:02 AM To: schism-dev/schism @.> Cc: Y. Joseph Zhang @.>; Mention @.> Subject: Re: [schism-dev/schism] :bug: Wrong version generated by gen_version.py (Issue #84)

[EXTERNAL to VIMS received message]

@josephzhang8https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjosephzhang8&data=05%7C01%7Cyjzhang%40vims.edu%7C24c88067178a46b65f8108db1e32438a%7C8cbcddd9588d4e3b9c1e2367dbdf1740%7C0%7C0%7C638136973465404876%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Z69y4Q94FcEkS8WNfL8sXaTMvypl44eXymHJEk2Gtk4%3D&reserved=0 @water-ehttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fwater-e&data=05%7C01%7Cyjzhang%40vims.edu%7C24c88067178a46b65f8108db1e32438a%7C8cbcddd9588d4e3b9c1e2367dbdf1740%7C0%7C0%7C638136973465404876%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=o0sVeg2%2FO%2BuuFUmKtYiE%2FJ%2BooRetOf2uaLJ1gWh4%2FYM%3D&reserved=0 A bit more context might make our use-case/intentions clearer

1. A conda package installs an executable + necessary libraries. Whoever installs the schism conda package does not need to know anything about compiling schism and/or manipulating the version on runtime. Furthermore, it would not be uncommon for such a user to have multiple versions of the package installed (in different envrionments). All that user expects is that schism -v/--version will print something sensible like make -v/--version, gcc -v/--version and cmake --version. The output could contain additional information that has to do with the compilation/configuration options, pretty much like gcc -v does, but you could also have a dedicated command for that (similar to docker --info).
2. @gbreyhttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgbrey&data=05%7C01%7Cyjzhang%40vims.edu%7C24c88067178a46b65f8108db1e32438a%7C8cbcddd9588d4e3b9c1e2367dbdf1740%7C0%7C0%7C638136973465404876%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=DgVfzyFz9KZdGLnBu9FWX6Wnb%2BX8Kx4zglKX2BJWWeI%3D&reserved=0 developed pyposeidon which, among other things, facilitates creating and running schism models. In pyposeidon the schism executable is provided as a path. The origin of the executable is irrelevant (compilation vs conda vs module vs whatever). As long as you provide a valid path, things should work. In this context it is important that the schism executable declares its version properly so that pyposeidon can choose the proper pre/post processing steps for the specific version.

- Reply to this email directly, view it on GitHubhttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fschism-dev%2Fschism%2Fissues%2F84%23issuecomment-1455920565&data=05%7C01%7Cyjzhang%40vims.edu%7C24c88067178a46b65f8108db1e32438a%7C8cbcddd9588d4e3b9c1e2367dbdf1740%7C0%7C0%7C638136973465404876%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=YqrQIJJha23IFansyHQJl3MfwlplaPEKUPrmIPQOYJU%3D&reserved=0, or unsubscribehttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAFBKNZ2PZ6UHCG2MV2YGVGTW2W737ANCNFSM6AAAAAAQKFRKR4&data=05%7C01%7Cyjzhang%40vims.edu%7C24c88067178a46b65f8108db1e32438a%7C8cbcddd9588d4e3b9c1e2367dbdf1740%7C0%7C0%7C638136973465404876%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=0ilPhyOEFWZcMfrvAdpxNEKLY%2Fp9r6BDfC2NbwcnRNE%3D&reserved=0. You are receiving this because you were mentioned.Message ID: @.**@.>>

[water-e]

Hi all, Let's bring these use cases back to the behavior:

1. Joseph, I want the semantic version number from Git to work fine even if it doesn't solve everyones issues. Doing the semantic number on the basis of Git mechanics and automatic generation is quite common and using the executable name is not a very modern or "fail safe" way. Most software (cmake --version, python --version ... use this system) use this system.

2. The buggy behavior was supposed to have been corrected October of last year. No one on the thread has directly said it doesn't work although I agree if you compiled it with the .git folder discarded it would not work without adding a manual override. The version reported by pschism -v in version 5.10.x should be useful and it works for me. To work, Git must be available at compile time, but not at run time.

3. Having Git be available is not intuitively precluded under most conda-related workflows. For instance, the conda libraries we build in our group are sometimes done on a CI tool like Jenkins based on Git tags and in that sequence we do have access to Git information at compile time. @brey, the things you wrote about the executables being delivered in different directories seems unrelated to whether you had Git on your system when you did the compile. I think it should work fine.

4. The comments above are restricted to 5.10. There is nothing we can do about v5.8.0, which is a tagged version written in stone. If folks are having problems mostly with old versions they should flag this as a problem with old versions. We can do some of the same things for v5.8 that we did for 5.10 and create 5.8.1, but repairing this years later is less compelling and there are some complications.

5. Finally there is the question of OLDIO vs NEWIO. The reason this came up was that we were hearing "what they really want is to be able to tell OLDIO from NEWIO". Both OLDIO and NEWIO are available in v5.10 and this would be the recommendation. The truth is that the version number tells you very little about what is in your version of schism, which is why when we created the build system we stacked everything in the executable name.

@brey can you fill in about how the code is compiled for conda? Where this happens and why you wouldn't have access to git?

[pmav99]

@water-e The conda recipe was downloading the tar.gz files, therefore it didn't have access to the .git directory. That's why the -v didn't work. This is the relevant code https://github.com/schism-dev/schism/blob/b3ba0c461e1e021c0ebfcd1c7b395b15a43ce995/conda.recipe/meta.yaml#L12-L15

We think it should be possible to use the git repo instead, @brey is looking into it.

we stacked everything in the executable name

Just as an alternative, schism -v could also print the variables + values of the SCHISM components as defined in e.g. cmake/SCHISM.local.build. This would be both less fragile than the filename and offer more information to the users.

[josephzhang8]

Indeed -v would be much more user friendly. However I'd like to being another perspective. HPC upgrades are very common and frequent (e.g. module changes etc), so the chances of not being able to execute pschism at all are high.

Regards,

Joseph Zhang (804)684 7595 (office) SCHISM web: http://ccrm.vims.edu/schism/ From: pmav99 @.> Sent: Tuesday, March 7, 2023 4:28 PM To: schism-dev/schism @.> Cc: Y. Joseph Zhang @.>; Mention @.> Subject: Re: [schism-dev/schism] :bug: Wrong version generated by gen_version.py (Issue #84)

[EXTERNAL to VIMS received message]

@water-ehttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fwater-e&data=05%7C01%7Cyjzhang%40vims.edu%7C8a7d8dfb60434e93cc3f08db1f52d39d%7C8cbcddd9588d4e3b9c1e2367dbdf1740%7C0%7C0%7C638138212824203610%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=7aTM%2F6qh0LhWqE46BXc7zCfhOwDhieqguYqDCW86Qlo%3D&reserved=0 The conda recipe was downloading the tar.gz files, therefore it didn't have access to the .git directory. That's why the -v didn't work. This is the relevant code https://github.com/schism-dev/schism/blob/b3ba0c461e1e021c0ebfcd1c7b395b15a43ce995/conda.recipe/meta.yaml#L12-L15https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fschism-dev%2Fschism%2Fblob%2Fb3ba0c461e1e021c0ebfcd1c7b395b15a43ce995%2Fconda.recipe%2Fmeta.yaml%23L12-L15&data=05%7C01%7Cyjzhang%40vims.edu%7C8a7d8dfb60434e93cc3f08db1f52d39d%7C8cbcddd9588d4e3b9c1e2367dbdf1740%7C0%7C0%7C638138212824359849%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=DyRkdWrD5VTYjoc5wu4tEYTfoiG0JUPyCU%2FftQ8xeAE%3D&reserved=0

We think it should be possible to use the git repo instead, @breyhttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fbrey&data=05%7C01%7Cyjzhang%40vims.edu%7C8a7d8dfb60434e93cc3f08db1f52d39d%7C8cbcddd9588d4e3b9c1e2367dbdf1740%7C0%7C0%7C638138212824359849%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=9mlj3tY%2Bf83OFPPtK%2B9oqMvCVn4k%2FFh%2Bobst0mo0Ce4%3D&reserved=0 is looking into it.

we stacked everything in the executable name

Just as an alternative, schism -v could also print the variables + values of the SCHISM components as defined in e.g. cmake/SCHISM.local.build. This would be both less fragile than the filename and offer more information to the users.

- Reply to this email directly, view it on GitHubhttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fschism-dev%2Fschism%2Fissues%2F84%23issuecomment-1458898076&data=05%7C01%7Cyjzhang%40vims.edu%7C8a7d8dfb60434e93cc3f08db1f52d39d%7C8cbcddd9588d4e3b9c1e2367dbdf1740%7C0%7C0%7C638138212824359849%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=B5EhBNIpWlFoYR8BlcDITh1kJ3zeTVaGoEGH5Ilxayc%3D&reserved=0, or unsubscribehttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAFBKNZ3HGVBJZEAHCK4M6MLW26R57ANCNFSM6AAAAAAQKFRKR4&data=05%7C01%7Cyjzhang%40vims.edu%7C8a7d8dfb60434e93cc3f08db1f52d39d%7C8cbcddd9588d4e3b9c1e2367dbdf1740%7C0%7C0%7C638138212824359849%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=l5wd0gla%2FZXVUUe3fy6ybaSkocyXKbmZ6d0NPacyIzo%3D&reserved=0. You are receiving this because you were mentioned.Message ID: @.**@.>>

[brey]

Dear All,

I have successfully modified the conda recipe to use git and it works as expected. After installation with conda one gets

❯ schism -v                      

 schism v5.10.1
 git hash 1955928f

So in terms of #13 this is not an issue anymore. This also takes care of #50 as well.

One thing, I would like to clarify is the following:

Going forward, there will be no tagging on the master branch and all tagging will be on the corresponding branch. T/F?

In terms of adding more info on the cmake flags of the build we can explore some options and come back with ideas in a new issue.

[josephzhang8]

Yes tags are only issued from release branches.

Regards,

Joseph Zhang (804)684 7595 (office)

SCHISM web: http://ccrm.vims.edu/schism/ From: George Breyiannis @.> Sent: Wednesday, March 8, 2023 6:32 AM To: schism-dev/schism @.> Cc: Y. Joseph Zhang @.>; Mention @.> Subject: Re: [schism-dev/schism] :bug: Wrong version generated by gen_version.py (Issue #84)

[EXTERNAL to VIMS received message]

Dear All,

I have successfully modified the conda recipe to use git and it works as expected. After installation with conda one gets

❯ schism -v

schism v5.10.1

git hash 1955928f

So in terms of #13https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fschism-dev%2Fschism%2Fissues%2F13&data=05%7C01%7Cyjzhang%40vims.edu%7C503124b7ec5041df5a6808db1fc8b16b%7C8cbcddd9588d4e3b9c1e2367dbdf1740%7C0%7C0%7C638138719076004696%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=dPj1GJfiMgeISlXxECpD4LvDC5g7F1SyHho%2Big6flXE%3D&reserved=0 this is not an issue anymore. This also takes care of #50https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fschism-dev%2Fschism%2Fissues%2F50&data=05%7C01%7Cyjzhang%40vims.edu%7C503124b7ec5041df5a6808db1fc8b16b%7C8cbcddd9588d4e3b9c1e2367dbdf1740%7C0%7C0%7C638138719076160926%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=XgWau9pA9M0uYKxTXT0P0GnQvYF4aV9NxF4lrhXRIJM%3D&reserved=0 as well.

One thing, I would like to clarify is the following:

Going forward, there will be no tagging on the master branch and all tagging will be on the corresponding branch. T/F?

In terms of adding more info on the cmake flags of the build we can explore some options and come back with ideas in a new issue.

— Reply to this email directly, view it on GitHubhttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fschism-dev%2Fschism%2Fissues%2F84%23issuecomment-1460023174&data=05%7C01%7Cyjzhang%40vims.edu%7C503124b7ec5041df5a6808db1fc8b16b%7C8cbcddd9588d4e3b9c1e2367dbdf1740%7C0%7C0%7C638138719076160926%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=4oRaZVVf3%2BWvYIm3U0zyzTwPk5rwOjQw80rIqvOS%2Fv8%3D&reserved=0, or unsubscribehttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAFBKNZ3C4LRWQD55GG5H6T3W3BUZ7ANCNFSM6AAAAAAQKFRKR4&data=05%7C01%7Cyjzhang%40vims.edu%7C503124b7ec5041df5a6808db1fc8b16b%7C8cbcddd9588d4e3b9c1e2367dbdf1740%7C0%7C0%7C638138719076160926%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=TME9vbulC0rNLgAKJLe3YccEkPnnKfknUvMiP0PzeiY%3D&reserved=0. You are receiving this because you were mentioned.Message ID: @.**@.>>