Hello Dennis,
You've probably seen that last email from Ed, who is our mentor on
the RMF project. Our issue in a nutshell: We are in the incubation
phase and are currently designing a useful, lightweight release
process. What we have so far is documented here:
http://wiki.eclipse.org/RMF/Release_Process
Our goal (what we want): easily identifiable, scheduled
releases.
Our plan so far (how to realize it): to use label of the
year-month format (similar to Ubuntu's 11.10 version number scheme)
that we use in bugzilla and as git tags.
The catch: This doesn't quite conform to the Eclipse
guidelines
The reasoning: As we have multiple features in our project,
propagating feature version numbers as the project version number
would not work, as the feature version numbers may diverge. Using a
"loose" datestamp seems like a practical way to regain a meaning
that is useful at the same time.
The question: If this is a bad idea, why? Is there a better
way to achieve what we're trying to do?
One more thought: Ed seems to suggest to add another feature,
and overarching SDK feature. If we would introduce a construct like
that, its feature version id could be used as the project version
number. My concern here is that future version number are not
predictable (e.g., 1.2.3 -> 1.3.0 or 1.2.4?). Therefore this
format is not suited for milestones in bugzilla.
Thanks in advance for your help!
- Michael
On 01/16/2012 05:36 PM, Ed Merks wrote:
Michael,
No, I'm not subscribed.
I'm certainly not release engineering expert. It's
probably might be better to chat with Dennis Hübner.
So you're saying there isn't an overall feature that composes all
these separate features? I.e., no overall SDK? It's just five
features?
If you're going to use a date, I'd still follow a more common
pattern like yyyymmdd:
http://download.eclipse.org/eclipse/downloads/drops4/M20120112-0600/index.php
Cheers,
Ed
On 16/01/2012 4:30 PM, Michael Jastram wrote:
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)
--
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)
|
