[took another look at this while looking for something else] -- replying below to -- From: jan i [mailto:[email protected]] Sent: Saturday, December 20, 2014 12:24 To: [email protected]; [email protected] 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 <[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
