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 <[email protected]> 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 > > > >
