Versions for non-release commits

[goodmami]

I think we need a strategy for updating Version.lsp for commits that are not release commits. If we keep the version string from the previous release, we won't easily know if a compiled grammar image is from the pristine release or some later commit. The ERG uses ERG (trunk) for the trunk version, then changes it to, e.g., ERG (1214) only for the tagged release. The problem with this is you don't know what stage "trunk" is in (e.g., is it pre or post 1214?).

I just made release 2017-09-08, so I will try changing the version on the develop branch to 2017-09-08-develop until we decide a strategy. Perhaps we can use a pre-commit hook so that, on commit, if Version.lsp is unchanged, update it to today's date with the UTC time (e.g. Jacy (2017-09-08 16:48:32)). A manual change with a friendlier date (e.g. Jacy (2017-09-08)) would not trigger the hook, so you can manually set those for releases. Sound good?

[goodmami]

The reason for using a pre-commit hook is that I don't expect developers to remember to set Version.lsp for each commit. If you don't want those Version.lsp diffs polluting the history, then the ${date}-develop strategy might work better, although it's less precise.

[fcbond]

Sounds good, please go ahead and add the hook (and then maybe explain what you did so we can do the same thing for Zhong and Indra).

…

On Sat, Sep 9, 2017 at 7:55 AM, Michael Wayne Goodman < ***@***.***> wrote: The reason for using a pre-commit hook is that I don't expect developers to remember to set Version.lsp for each commit. If you don't want those Version.lsp diffs polluting the history, then the ${date}-develop strategy might work better, although it's less precise. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#50 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABD8xrgoxga2ASdtxqLPU-Uq_D786LF-ks5sgdPmgaJpZM4PRzlV> .

-- Francis Bond <http://www3.ntu.edu.sg/home/fcbond/> Division of Linguistics and Multilingual Studies Nanyang Technological University

[goodmami]

Ok, I've got it working, but it turns out that you can't commit the hook code itself to the repository. So there's a one-time step developers need to do to use it (copy the hook file to their .git/hooks/ directory).

So I can commit the hook to, e.g., utils/git-hooks/pre-commit, then each developer (each repository clone, rather) copies this themselves. Once set, it should then work for each commit.

If you want to proceed with that solution, would you rather use the commit hash (if I can get it) for the version? The date is only linear, but a repository is branching, so a new commit on a stale branch, or on top of an old commit in the master branch, would look newer than the latest HEAD on master.

[fcbond]

G'day,

On Sun, Sep 10, 2017 at 3:04 AM, Michael Wayne Goodman < ***@***.***> wrote: Ok, I've got it working, but it turns out that you can't commit the hook code itself to the repository. So there's a one-time step developers need to do to use it (copy the hook file to their .git/hooks/ directory). So I can commit the hook to, e.g., utils/git-hooks/pre-commit, then each developer (each repository clone, rather) copies this themselves. Once set, it should then work for each commit.

OK. We can add a note to do this.

If you want to proceed with that solution, would you rather use the commit hash (if I can get it) for the version? The date is only linear, but a repository is branching, so a new commit on a stale branch, or on top of an old commit in the master branch, would look newer than the latest HEAD on master.

I think people not using master should be able to deal with different versions, and I would prefer a simple to understand version string, so I think that the original proposal is better (but could still be persuaded otherwise).

…

-- Francis Bond <http://www3.ntu.edu.sg/home/fcbond/> Division of Linguistics and Multilingual Studies Nanyang Technological University

[goodmami]

Ok it's committed to develop. The Version.lsp in the develop branch was created by the script. There's some info here: https://github.com/delph-in/jacy/tree/develop/utils/git-hooks

On master, if will generate something like Jacy (2017-09-10 07:11:19+00:00). On other branches, it will generate something like Jacy-branchname (2017-09-10 07:11:19+00:00). It won't silently change Version.lsp, it will prompt the committer, who can then choose to use the new version string, continue without changing Version.lsp, or abort the commit. If Version.lsp is changed manually and added (i.e., staged), then a new version string won't be generated.

Let me know if this works for you.

[goodmami]

@fcbond I merged your recent changes on 'master' and then made 'develop' the default branch. Please do a git checkout develop when convenient, and work from that branch from now on. Releases will be pushed to the master branch in the future.