[cadenmyers13]

As per the instructions in the file, bump this before a release

[cadenmyers13]

@sbillinge ready for review

[SYMSCAE]

@cadenmyers13 Maybe we should let @sbillinge to update the this upon tagging/release? Otherwise our ci will fail. The FALLBACK_VERSION thing works pretty oddly since it was actively fetched. I'm thinking of removing/altering this check but lack of context.

[sbillinge]

Just let me know what to do in what order and I will do it. Let's also think about repairing it so it is another in the future. The gift that keeps on giving. But make an issue for the next release. Let's just work to get this out.

[sbillinge]

@cadenmyers13 I don't remember closing this so I may have done it by mistake on my phone. If we still need it, we may need to reopen it, but GH is not letting me.

[cadenmyers13]

@SYMSCAE Do you know how we should handle this?

[SYMSCAE]

@SYMSCAE Do you know how we should handle this?

@cadenmyers13 A good way is simply not to verify fallback with the git info tag, i.e. to decouple these two paths and move the tag check work to the release workflow. For instance, if a git tag is resolvable, use that (1.4.1.post80 or smh); else, just use the fallback path.
I suppose this was originally brought up to make those who directly download source instead of git pull to build properly but it seems to make things a bit complicated.

[sbillinge]

I am ok making it more robust for general users and not handling specific edge cases of that complicated the code.

TL;Dr remove this is it is causing is issues and deal with any fallout when someone complains