corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <dennis.hamil...@acm.org>
Subject RE: [DISCUSS] Corinthia Versioning Scheme
Date Tue, 13 Jan 2015 23:26:56 GMT
[took another look at this while looking for something else]

 -- replying below to --
From: jan i [mailto:jani@apache.org] 
Sent: Saturday, December 20, 2014 12:24
To: dev@corinthia.incubator.apache.org; orcmid@apache.org
Subject: Re: [DISCUSS] Corinthia Versioning Scheme

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.

<orcmid>
   I agree that the release of the source, and the relationships among 
   releases are the key ASF Releases.  The major.minor.fix scheme works
   great for that.

   In fact, some projects do need -suffix values (not sure why I said
   prefix before).  They are for things like release candidates.  Whether
   We ever have a thing like a -beta or not is something that only 
   matters if it comes up.  At least the naming scheme provides for it
   if it is ever needed.

   Sometimes the suffix is not removed, it being part of the name and
   the version number will advance if there is another one, with or 
   without the suffix.

   What I don't know, is what happens when, say, -rc2 becomes accepted
   as the release.  Does the -rc2 simply get dropped?  Or are the 
   artifacts already names as if they are for the released version?

   I must look more closely at the Semantic Versioning scheme to see if
   there is any wisdom about that <http://semver.org/spec/v2.0.0.html>.

   My inclination is that release candidates advance the version number.
   That is, there might be 1.9.0-rc1, then 1.9.1-rc2, 1.9.2-rc3, etc.
   The approved stable artifact could simply be named 1.9.2 in this
   example, but it would be confused with any previous 1.9.x (proposed)
   Release.
</orcmid>  

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.

<orcmid>
   For simplicity, let me refer to built objects as distributions. Some-
   times there are distributions built concurrent with and part of 
   management of a Release, even though they are not the release as 
   such.  I think this establishes at least two things:
     1. It confirms that the source code builds.
     2. It provides for testing of the built code, identification in
        bug reports, etc., and it defends against regressions in the
        source.
     3. It makes built objects available for use and it establishes
        their provenance with regard to the ASF Release they depend on
        as their upstream source.
</orcmid>

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.

<orcmid>
   I think built objects that the project creates (or others create)
   working exclusively from the provided source and its dependencies
   should have build identifiers for the builds they are.  The Semantic
   Version Number of that source becomes the version of the distribution
   to, but there can be build differentiators, such as the difference
   between +win32x86, +win32x64, +armKFire, etc.

   I don't know how these differences are reflected in the artifact,
   but they are likely reflected in the installers and also any 
   introduction into an app store of some kind.

   It is also my thinking that third-party versions based on the same
   source version might have suffixes, such as -GitHub+win32x86 or such.
</orcmid>

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).

<orcmid>
   Yes, we need identifiable components and also versions that bugs
   apply to, versions that bugs are fixed in.  All in JIRA.
</orcmid>

@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).

<orcmid>
   I'm still thinking about it.  
   We do need to have more discussion on exactly what the buildable 
   components are.  I also think we may need more insight into the 
   workflow that produces built objects, and what they are and how they 
   are deployed (or how deployables are built out of them).
</orcmid>

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


Mime
View raw message