emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* minor problem on major version number
@ 2014-06-26 16:14 Nick Dokos
  2014-06-26 17:44 ` Achim Gratz
  2014-06-26 18:15 ` Alexander Baier
  0 siblings, 2 replies; 4+ messages in thread
From: Nick Dokos @ 2014-06-26 16:14 UTC (permalink / raw)
  To: emacs-orgmode

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: minor problem on major version number
  2014-06-26 16:14 minor problem on major version number Nick Dokos
@ 2014-06-26 17:44 ` Achim Gratz
  2014-06-26 18:25   ` Nick Dokos
  2014-06-26 18:15 ` Alexander Baier
  1 sibling, 1 reply; 4+ messages in thread
From: Achim Gratz @ 2014-06-26 17:44 UTC (permalink / raw)
  To: emacs-orgmode

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: minor problem on major version number
  2014-06-26 16:14 minor problem on major version number Nick Dokos
  2014-06-26 17:44 ` Achim Gratz
@ 2014-06-26 18:15 ` Alexander Baier
  1 sibling, 0 replies; 4+ messages in thread
From: Alexander Baier @ 2014-06-26 18:15 UTC (permalink / raw)
  To: Nick Dokos; +Cc: emacs-orgmode

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: minor problem on major version number
  2014-06-26 17:44 ` Achim Gratz
@ 2014-06-26 18:25   ` Nick Dokos
  0 siblings, 0 replies; 4+ messages in thread
From: Nick Dokos @ 2014-06-26 18:25 UTC (permalink / raw)
  To: emacs-orgmode

Achim Gratz <Stromeko@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

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2014-06-26 18:25 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-06-26 16:14 minor problem on major version number Nick Dokos
2014-06-26 17:44 ` Achim Gratz
2014-06-26 18:25   ` Nick Dokos
2014-06-26 18:15 ` Alexander Baier

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).