Dynamic versioning #20
Conversation
Signed-off-by: Jesse Gorzinski <17914061+ThePrez@users.noreply.github.com>
Signed-off-by: Jesse Gorzinski <17914061+ThePrez@users.noreply.github.com>
Signed-off-by: Jesse Gorzinski <17914061+ThePrez@users.noreply.github.com>
Signed-off-by: Jesse Gorzinski <17914061+ThePrez@users.noreply.github.com>
Signed-off-by: Jesse Gorzinski <17914061+ThePrez@users.noreply.github.com>
Signed-off-by: Jesse Gorzinski <17914061+ThePrez@users.noreply.github.com>
There was a problem hiding this comment.
I'm not sure why this is adding classes to the .gitignore. Could cause problems if we really add a BuildInfo class later.
There was a problem hiding this comment.
We will run into inconvenience if we try to add a git-managed BuildInfo.java, so we aren't at that much risk of accidental ignores
There was a problem hiding this comment.
Does this new class need a prolog, like all the other classes in JTOpen
There was a problem hiding this comment.
Good call. It should have something. I am not a fan of the classic prolog since we can use short abbreviated copyright/license headers. Still, probably should use the same for consistency's sake
There was a problem hiding this comment.
I liked having the change flag in the version string. That way we can easily tell what version of code we have instead of having to look up the versioning information. Can we keep that?
There was a problem hiding this comment.
I would like to discuss this further. I wouldn't want to remove something useful but I also don't understand the utility of the change flag.
Maybe there is a solution that can stay mostly automated but still have the same usefulness. What if this was generated from the commit id?
No description provided.