Mailing-List: contact dev-help@arrow.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@arrow.apache.org
Date: Mon, 19 Dec 2016 20:23:58 +0000 (UTC)
From: "Uwe L. Korn (JIRA)" <jira@apache.org>
To: dev@arrow.apache.org
Message-ID: <JIRA.13029249.1482179034000.556871.1482179038388@Atlassian.JIRA>
In-Reply-To: <JIRA.13029249.1482179034000@Atlassian.JIRA>
References: <JIRA.13029249.1482179034000@Atlassian.JIRA> <JIRA.13029249.1482179034618@arcas>
Subject: [jira] [Created] (ARROW-430) Python: Better version handling
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
archived-at: Mon, 19 Dec 2016 20:24:01 -0000

Uwe L. Korn created ARROW-430:
---------------------------------

             Summary: Python: Better version handling
                 Key: ARROW-430
                 URL: https://issues.apache.org/jira/browse/ARROW-430
             Project: Apache Arrow
          Issue Type: Improvement
    Affects Versions: 0.1.0
            Reporter: Uwe L. Korn
             Fix For: 0.2.0


We need better version handling for Python releases. {{setuptools_scm}}=C2=
=A0sadly conflicts a bit a with the workflow of conda-forge+git. In general=
, it seems that generating a version from a non-tagged git archive is not p=
ossible.

For tagged archives, we can use git's {{export-subst}} functionality but th=
at will result in non-deterministic tarballs from Github.

My currently preferred (when not really clean but at least integrated into =
the release process) solution would be to read {{java/pom.xml}}=C2=A0and us=
e this version number. For PEP-440 compability we would need to replace {{S=
NAPSHOT}} with {{pre1}}.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)