[O] minor problem on major version number

2014-06-26 Thread Nick Dokos 
I have some backward-compat code that does this:

--8---cut here---start-8---
;;(setq major-version (string-to-number (nth 0 (split-string (org-version) 
[.]
(setq major-version 8)

(if ( major-version 8)
(progn
  (require 'org-latex)
  ...
  (progn
(require 'ox-latex)
...
--8---cut here---end---8---

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?

Thanks,
Nick

Re: [O] minor problem on major version number

2014-06-26 Thread Achim Gratz 
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:

--8---cut here---start-8---
GITVERSION ?= $(shell git describe --match release\* --abbrev=6 HEAD)
ORGVERSION ?= $(subst release_,,$(shell git describe --match release\* 
--abbrev=0 HEAD))
--8---cut here---end---8---

I'm tempted to install that in targets.mk to avoid further breakage by
malformed tags.


Regards,
Achim.
-- 
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: [O] minor problem on major version number

2014-06-26 Thread Alexander Baier 
On 2014-06-26 18:14 Nick Dokos wrote:
 I have some backward-compat code that does this:

 (setq major-version (string-to-number (nth 0 (split-string
 (org-version) [.]

It does not work in this situation, because beta_8.3 is not a valid
version string, but version might be interesting for you.

HTH,
-- 
Alexander Baier

Re: [O] minor problem on major version number

2014-06-26 Thread Nick Dokos 
Achim Gratz strom...@nexgo.de 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