You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@corinthia.apache.org by "Dennis E. Hamilton" <or...@apache.org> on 2014/12/20 03:22:57 UTC
[DISCUSS] Corinthia Versioning Scheme
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
RE: [DISCUSS] Corinthia Versioning Scheme
Posted by "Dennis E. Hamilton" <de...@acm.org>.
[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 <or...@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
Re: [DISCUSS] Corinthia Versioning Scheme
Posted by jan i <ja...@apache.org>.
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 <or...@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
>
>
>
>