-
Notifications
You must be signed in to change notification settings - Fork 84
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
🐛 Wrong version generated by gen_version.py #84
Comments
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. |
I notice the output of |
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. |
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 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:
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:
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. |
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?
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 |
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] 🐛 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 GitHub<https://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 unsubscribe<https://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: ***@***.******@***.***>>
|
Jamal, 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. |
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] 🐛 Wrong version generated by gen_version.py (Issue #84)
[EXTERNAL to VIMS received message]
Thanks @water-e<https://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 GitHub<https://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 unsubscribe<https://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: ***@***.******@***.***>>
|
I agree, git tag is not a solution, but a band-aid :)
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 |
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. |
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. |
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] 🐛 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 GitHub<https://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 unsubscribe<https://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: ***@***.******@***.***>>
|
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] 🐛 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 GitHub<https://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 unsubscribe<https://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: ***@***.******@***.***>>
|
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. |
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.
|
Yep okay, I'm using gnu make, my process is
Output from make includes
but output executable is, unfortunately, still |
See also #40 |
@hot007 I am suspecting that the executable name is hard defined in the With the compiled executable if you do |
Ah, you are right! We had |
I guess you can simply change the EXEC value to pschism-`git describe`? That will add the output from FYI:
|
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 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. |
It is indeed clear from all the discussion/examples that using 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. |
Dear All, may I re-iterate issue #50 and ask for a native |
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] 🐛 Wrong version generated by gen_version.py (Issue #84)
Dear All, may I re-iterate issue #50<https://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 GitHub<https://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 unsubscribe<https://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: ***@***.***>
|
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 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. |
"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] 🐛 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 dunamai<https://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 #13<https://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 GitHub<https://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 unsubscribe<https://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: ***@***.******@***.***>>
|
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). |
@josephzhang8 @water-e
|
Hi all,
@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? |
@water-e The conda recipe was downloading the tar.gz files, therefore it didn't have access to the Lines 12 to 15 in b3ba0c4
We think it should be possible to use the git repo instead, @brey is looking into it.
Just as an alternative, |
Dear All, I have successfully modified the ❯ 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 |
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 -
However, the actual output is -
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, asstofs3d-atl.v1.1.0
is in the list as a different version numbering.git tag -l
outputs the alphabetical orderif sorted by tagger date
git tag --sort=taggerdate
, the output isFor now a probable fix is
--sort="version:refname"
as ingit tag -l --sort="version:refname"| grep v* | tail -n 1
to get the last 'v' tag, andgit rev-parse --short HEAD
to get the sha. As of writing the output of the commands are following -Thanks.
The text was updated successfully, but these errors were encountered: