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