Mailing-List: contact dev-help@corinthia.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@corinthia.incubator.apache.org
MIME-Version: 1.0
In-Reply-To: <010d01d01bfb$e23e2850$a6ba78f0$@apache.org>
References: <010d01d01bfb$e23e2850$a6ba78f0$@apache.org>
Date: Sat, 20 Dec 2014 21:23:43 +0100
Message-ID: 
 <CAK2iWdT5XFbzvF9wEQ1qcGVMzW4H6Qw+QdgCdwecM8gmBXG=7w@mail.gmail.com>
Subject: Re: [DISCUSS] Corinthia Versioning Scheme
From: jan i <jani@apache.org>
To: "dev@corinthia.incubator.apache.org" <dev@corinthia.incubator.apache.org>,
	"orcmid@apache.org" <orcmid@apache.org>
Content-Type: multipart/alternative; boundary=089e0158b7e4070b8a050aab9a96

--089e0158b7e4070b8a050aab9a96
Content-Type: text/plain; charset=UTF-8

HI.

I think you raise a very important point, with implications that are all
too often forgotten. Thanks for taking the initative.

I am a simply guy, and like to keep things simple, therefore I am all for
the good old x.y.z scheme. I especially dont like the - prefix, as it
implies we could have a special release for a given platform.

We have to remember that in Apache, the only release that counts is the
source release ! any binary that we make available is not a release
artifact, but a convenience for our end-users.

Without having really counted, my feeling is that 2/3 of the projects only
release source. We should also provide both library and editor on different
platforms, but as a compiled version of the release...not as a release in
itself.

It would really be beneficial to use jira track in which version which
bug/enhancement is destined for (or solved in). I have seen a couple of
other projects, where the release notes is a long list of solved jira
issues. Jira has a text field for release, which I as admin should be able
to prefill (make a combobox).

@Dennis, may I suggest you write a suggestion out of this discussion, and
we put it up on our wiki (yes yes it is soon 24december).

rgds
jan i.


On 20 December 2014 at 03:22, Dennis E. Hamilton <orcmid@apache.org> wrote:

> As we start setting up the JIRA issue tracker, we need to determine how to
> identify what code an issue applies to and what the target is for any fix.
>
> There are also forensic and authentication needs for a clear-cut
> version-identification scheme.  It is also important in digging related
> code out of a repository, replicating an issue and also preparing
> version-specific fixes.
>
> I am talking about the typical 0.9.1-beta and 4.1.1 flavors of version
> identifiers.  These apply to delivered code and to APIs and libraries.
>
> I have had my eye on the Semantic Versioning scheme <
> http://semver.org/spec/v2.0.0.html> and I wonder if it is useful to start
> thinking about that for multi-platform delivery of Corinthia artifacts.
>
> Using Semantic Versioning, 0.9.1-beta would work already, and so would
> 1.7.5-rc1.  An unfamiliar scheme is used to indicate builds though.
> Examples of this would be something like 4.1.1+Win.x64.en-US or
> 1.7.5-rc1+iOS.debug for particular build cases off of portable source code.
>
> It is probably easier to agree on the major.minor.patch triple and the
> "-"-prefix qualifiers when used.  But if we are looking at providing
> multi-platform binaries, there needs to be a way to be specific.  Not being
> precise here leads to too much work communicating about what artifact is
> someone talking about, and it would be good to have an aligned structure in
> advance.  (JIRA issues probably don't need to have tags that fine, although
> an issue might need to be quite specific.)
>
> Just thinking out loud.  I could easily bike-shed this all by myself.  I
> think I can resist that.
>
>  - Dennis
>
>
>
>

--089e0158b7e4070b8a050aab9a96--