On Sun, 16 Oct 2016 09:18:02 -0700 (PDT)
"Edward K. Ream" <edream...@gmail.com> wrote:
> At present, leoVersion.py gets version info by parsing
> leo/core/commit_timestamp.json. There are at least two unacceptable
> problems with this approach:
> 1. The dates don't get updated if a developer (like me!) forgets to
> install the git hooks.
> Just today I noticed that the last update was supposedly in July!
Heh, I don't think it's the end of the world if this happens, I guess
we / I could set up some sort of monitoring for that case, but just
noticing it (eventually) and installing the hooks works too.
> 2. Continually changing commit_timestamp.json creates merge conflicts.
Which can be resolved with
git checkout --ours leo/core/commit_timestamp.json
(seeing it's not that critical which one you use).
Certainly in a git repo. commit_timestamp.json isn't needed.
The point of it was to give useful, *fine grained* version ID in non-git
contexts. I think "you have to use git to use Leo" in an unreasonable
barrier, seeing not all Leo users are coders and therefore may never
use a VCS, and I usually point people to
to get the current Leo. There's no git repo. in that .zip.
fficial releases don't offer fine grained version info., the first
thing we'd tell someone with a problem to try is running the latest
code, and if they're getting it from master.zip, commit_timestamp.json
So I'd argue for leaving commit_timestamp.json as is and living with
the two shortcomings you identified. But if it's not bearable, we can
do something like you suggest.
> There is a much easier way. Rather than parsing
> commit_timestamp.json, we can get info about the last commit from
> "git log -1". Like this:
> p = subprocess.Popen(
> ["git", "log" , '-1', '--date=default-local'],
> out, err = p.communicate()
> out = g.toUnicode(out)
> m = re.search('commit (.*)\n', out)
> commit = m.group(1)[0:8].strip() if m else ''
> m = re.search('Date: (.*)\n', out)
> date = m.group(1).strip() if m else '
> This works well in my tests.
> For official releases, we expect that git won't be installed, or that
> "git log" will fail because the official release contains no .git
> directory. Either way, the code will catch exceptions thrown by
> subprocess and return the official (static) release date defined in
> My release testing will ensure that this approach works. Do you see
> any problems with it?
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send email to firstname.lastname@example.org.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.