Re: [rmf-dev] Fwd: Re: Some questions towards RMF release

[Michael Jastram <michael@xxxxxxxxxx>]

Hi Ed,

first, are you subscribed to rmf-dev, or should I continue to CC you?

Regarding your answer to Lukas' question, let me elaborate a bit:

I think the version number of your bundles is very important to your clients.  It's a statement about the API.

I agree, as far as plugin and feature versions are concerned, but how about project versions?  RMF consists of five features, each with its respective plugins.  The feature version numbers will inevitable diverge (e.g., 1.2.3 -> 1.3.0 or 1.2.4?).  Eventually, the project version number would become fairly arbitrary.

The version number Lukas is referring to is essentially a label that defines an internal release.  As a such a release is defined by its release date, the reasoning was that it would be useful to make the date part of the label.

Once we join the Eclipse release train, we would use the labels provided by Eclipse (e.g. "Juno M5").  Until then, I would consider date-based release numbers quite useful.

I think a big part of the confusion stems from the terminology.  "Milestone" and "Release Candidate" have well-defined meanings within the Eclipse ecosystem.  What Lukas referred to as "Milestones" are actually internal project releases that are tied to our scrum-based iteration cycles.

So the real question is: If you would not recommend the proposed naming scheme, how should we form the project's version number instead?

Best,

- Michael

-------- Original-Nachricht --------

Betreff:	Re: Some questions towards RMF release
Datum:	Mon, 16 Jan 2012 15:20:36 +0100
Von:	Ed Merks <ed.merks@xxxxxxxxxx>
An:	Lukas Ladenberger <lukas.ladenberger@xxxxxx>

Lukas,

Comments below.

On 16/01/2012 3:12 PM, Lukas Ladenberger wrote:

Hello Ed,

I have some questions regarding the first release of the RMF project:

- Do we have to write a Release Review for incubation releases (see http://www.eclipse.org/projects/dev_process/development_process_2011.php#6_3_3_Release_Review) ?

Yes, I think so.

- We disscussed today about labeling conventions for releases. We determined the following conventions:

    - Releases label: Myy.mm (i.e. M12.01).

Releases are generally labeled with the version number of the release, e.g., 0.7.0.  Look at these as a good example of the platform's convention, which most projects try to follow:

http://download.eclipse.org/eclipse/downloads/

    - Release candidate label: Myy.mmRCx (i.e. M12.01RC1)

Please note: Our release label is simultaneously also our milestone label. As a consequence our first official release label would be: M12.01 and the label for the RCP zip product file would be: pror-M12.01-incubation-macosx.cocoa.x86_64.zip.

I don't think folks will expect to see numbers like that.

As you can see we have no "top level" version number like 3.7 in the eclipse project. Our "top level" version number would be simultaneously our milestone label. Is this ok?

I think the version number of your bundles is very important to your clients.  It's a statement about the API.  Information about the date of the build should generally appear in the finally qualifier that's also part of the version in the bundles and features.  Eventually you're likely to have maintenance streams, that are going on at the same time as you work on new releases, and then the dates will be very confusing.

Thank you.

Best regards,
Lukas

_______________________________________________
rmf-dev mailing list
rmf-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/rmf-dev

-- 
Michael Jastram (http://www.jastram.de, +49 (162) 274 83 94)
Geschäftsführer, Formal Mind GmbH (http://formalmind.com)
Wissenschaftler, Heinrich Heine Universität Düsseldorf (http://www.stups.uni-duesseldorf.de)
1. Vorsitzender, rheinjug e.V. (http://www.rheinjug.de)