[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [O] minor problem on major version number
From: |
Nick Dokos |
Subject: |
Re: [O] minor problem on major version number |
Date: |
Thu, 26 Jun 2014 14:25:03 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) |
Achim Gratz <address@hidden> writes:
> Nick Dokos writes:
>> After last night's git pull, org-version returns "beta_8.3" which
>> broke the major-version calculation above. I hardwired the org version
>> major number above, but I was wondering if we could agree on some
>> convention/method that will not break in the future - maybe an
>> org-major-version function?
>
> There already is a perfectly good convention available via C-h i
> version-to-list, which means the tag should have been named
> "release_8.3beta" and you do not need to invent your own version parsing
> code. Meanwhile, put these into local.mk:
>
> GITVERSION ?= $(shell git describe --match release\* --abbrev=6 HEAD)
> ORGVERSION ?= $(subst release_,,$(shell git describe --match release\*
> --abbrev=0 HEAD))
>
> I'm tempted to install that in targets.mk to avoid further breakage by
> malformed tags.
>
OK - thanks. I modified local.mk as suggested and replaced the
major-version calculation in the init file
(setq major-version (nth 0 (version-to-list (org-version))))
AFAICT, everything's fine.
Thanks,
Nick