From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Dokos Subject: Re: minor problem on major version number Date: Thu, 26 Jun 2014 14:25:03 -0400 Message-ID: <87wqc3r0jk.fsf@alphaville.bos.redhat.com> References: <871tubsl59.fsf@alphaville.bos.redhat.com> <87fvira7me.fsf@Rainer.invalid> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:58481) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X0EMS-0007fY-0p for emacs-orgmode@gnu.org; Thu, 26 Jun 2014 14:25:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X0EML-0005SL-3w for emacs-orgmode@gnu.org; Thu, 26 Jun 2014 14:25:27 -0400 Received: from plane.gmane.org ([80.91.229.3]:55332) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X0EMK-0005SF-Tx for emacs-orgmode@gnu.org; Thu, 26 Jun 2014 14:25:21 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1X0EMH-0005JH-Sz for emacs-orgmode@gnu.org; Thu, 26 Jun 2014 20:25:17 +0200 Received: from nat-pool-bos-t.redhat.com ([66.187.233.206]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 Jun 2014 20:25:17 +0200 Received: from ndokos by nat-pool-bos-t.redhat.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 Jun 2014 20:25:17 +0200 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Achim Gratz 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