Hi Fred,
Just a couple of my cents on you last post. See the comments in-line:
Frederic Plante wrote:
Rich,
Using a single strategy for both
components
would be ideal, but the answer "We are not providing “hot fixes”
as part of the GMF project" did not leave much room for project-wide
solutions that could accommodate everybody's requirements :-)
We don't have any specific clients
in
mind nor hotfix candidates. We simply believe the community may require
hot fixes and it seems very shortsighted not to leave room for this in
our version numbering scheme.
I guess this is the right moment to submit your vision of the version
numbering process for the community (introduce the meaning of a
"hotfix", etc) for the discussion. If you believe that we in GMF could
face problems like you described and would need "hotfixes", every other
project in the eclipse community would also do this. Lets raise this
issue / discuss in a broader audience and document it?
Given that plug-ins'
versions will evolve
independently according to the platform proposal, what's the big deal
if
the runtime uses 1.0.100 instead of 1.0.1 to leave room in case of
trouble?
To my best understanding, the process you're proposing compromises
this independency, for instance by forcing us to have in GMF 2.0
release plugins versions not smaller than 1.1.0, even though the
changed plugins could have no "visible" changes whatsoever... This
breaks the guidelines and compromises release version/plugin versions
independency.
Best regards,
Max
Thanks
- Fred
_________________________________
Frédéric Plante
Rational Software, IBM Software Group
Simply, act as a single team with
respect
to the policy on versioning and streams. Clearly, you are advocating
a different policy below for runtime vs. tooling components.
Which clients, in particular, are you referring to?
Thanks,
Rich
On 7/17/06 9:50 AM, "Frederic Plante" <fplante@xxxxxxxxxx>
wrote:
The statement about "act as a single team" is difficult to understand
here - we are talking about version number and providing hot fix in an
open way. The fact plug-in version numbers will diverge is inevitable;
even within the runtime and within the tooling... As another example
where
the runtime and the tooling will likely diverge is with regards to
moving
to "2.0.0" for our plug-in version since it would mean breaking
APIs and we don't intend to break API for "GMF 2.0".
The comment about "open source versus commercial" is even harder
to understand... What we are advocating here is to do what's best for
GMF's
clients.
Thanks
- Fred
_________________________________
Frédéric Plante
Rational Software, IBM Software Group
Richard Gronback <richard.gronback@xxxxxxxxxxx>
Sent by: gmf-dev-bounces@xxxxxxxxxxx
07/17/2006 10:20 AM
"GMF Project developer discussions."
<gmf-dev@xxxxxxxxxxx>
Re: [gmf-dev] CVS: GMF release state
tagged,
maintenance branch is created
Hi Fred,
Actually, I’d prefer that the GMF project act as a single team and not
continue to diverge along tooling vs. runtime and open source vs.
commercial
product planning lines.
Anyone else have strong feelings on this they’d like to voice?
Thanks,
Rich
On 7/17/06 8:41 AM, "Frederic Plante" <fplante@xxxxxxxxxx>
wrote:
Hi Rich,
It seems the tooling and the runtime components have different support
requirements. How about this:
* The tooling and the runtime can independently use whatever version
they need; this should have zero impact on our build infrastructure.
* If there is a need for a runtime hotfix then we (the runtime team)
will handle it ourself; no need for build infrastructure changes.
Thanks
- Fred
_________________________________
Frédéric Plante
Rational Software, IBM Software Group
Richard Gronback <richard.gronback@xxxxxxxxxxx>
Sent by: gmf-dev-bounces@xxxxxxxxxxx 07/17/2006 08:32 AM
Please respond to
"GMF Project developer discussions." <gmf-dev@xxxxxxxxxxx>
To
"GMF Project developer discussions." <gmf-dev@xxxxxxxxxxx>
cc
Subject
Re: [gmf-dev] CVS: GMF release state tagged, maintenance branch
is created
Hi Fred,
We are not providing “hot fixes” as part of the GMF project, just those
maintenance releases mentioned previously to align with the platform
and
other Callisto projects.
If we don’t anticipate needing such a stream, why think in terms of it
and complicate matters? I agree with Max’s interpretation of the
document, where if you ignore the first stream (which oddly does not
indicate
a maintenance stream) and think of their 1.1.0 stream as our 1.0.0
stream
and adjust accordingly, it all makes sense as written.
Best,
Rich
On 7/14/06 9:22 AM, "Frederic Plante" <fplante@xxxxxxxxxx>
wrote:
Hi Max,
What the runtime team does is inline with the document. What looks
different
is that we leave room for emergency fixes by assuming a stream for 1.0
hotfixes and that we branch GMF 1.0.1 off that hotfix stream from day
one;
details:
The document's first dev stream is what we consider the GMF 1.0
maintenance
stream. The stream would typically contain a few fixes for clients that
cannot afford the risk (perform regression tests on their components)
for
all the fixes we put in GMF 1.0.1 and/or can not afford to wait for GMF
1.0.1 to release. We currently do not have a branch for such a stream
and
we hope we won't need one. The idea is to avoid to be blocked by
plug-in
version if a hotfix is required. The version for modified plug-in for
this
stream would be 1.0.1.qualifier.
The document's second dev stream is what we consider the GMF 1.0.1
stream.
The stream is handled by the R1_0_maintenance branch. Modified
plug-ins'
version is 1.0.100, meaning GMF 1.0.1 can be installed over a GMF 1.0
hotfix.
The document's third dev stream is what we consider the GMF 2.0 stream.
HEAD is used for this stream. Because we do not plan to remove/change
existing
APIs in GMF 2.0, the version of our modified plug-ins will likely look
like 1.1.0.qualifier.
Thanks
- Fred
_________________________________
Frédéric Plante
Rational Software, IBM Software Group
Anthony Hunter/Ottawa/IBM@IBMCA
Sent by: gmf-dev-bounces@xxxxxxxxxxx 07/14/2006 07:38 AM
Please respond to
"GMF Project developer discussions." <gmf-dev@xxxxxxxxxxx>
To
"GMF Project developer discussions." <gmf-dev@xxxxxxxxxxx>
cc
Subject
Re: [gmf-dev] CVS: GMF release state tagged, maintenance
branch is created
Hi ,
We will have to review with the team again, our interpretation thought
that
1.0.100.qualifier was the way to go.
Cheers...
Anthony
--
Anthony Hunter mailto:anthonyh@xxxxxxxxxx
<mailto:anthonyh@xxxxxxxxxx>
<mailto:anthonyh@xxxxxxxxxx>
<mailto:anthonyh@xxxxxxxxxx>
Manager - Software Developer,
IBM Rational Software: Aurora Core Common / Modeling Tools
Phone: 613-591-7037
Max Feldman
<max.feldman@borl
and.com>
To
Sent by:
"GMF Project developer
gmf-dev-bounces@e
discussions." <gmf-dev@xxxxxxxxxxx>
clipse.org
cc
Subject
07/13/2006 07:00
Re: [gmf-dev] CVS: GMF release
PM
state tagged, maintenance
branch is
created
Please respond to
"GMF Project
developer
discussions."
<gmf-dev@eclipse.
org>
Hi Anthony,
As far as I can see in CVS, you are changing the MANIFEST.MF's to
1.0.100.qualifier in the maintenance branch (R1_0_maintenance) whereas
to
my best understanding, plugins which get bugfixes should become
1.0.1.qualifier in the maintenance branch, and 1.0.100.qualifier in the
HEAD. And this guarantees that the plugins from the next major version
(version 2.0) with these fixes will for sure override ones from the
maintenance release (1.0.1/1.0.2) in the user configuration.
Below is the excerpt from the document you were referring:
-cut-
Example: At the end of the development stream N, the version of the
plug-in
P is 2.4.8. When P receives its first bug fix in the development stream
N+1
or higher, then the version should be changed to 2.4.108. If P version
2.4.8 needs to receive a bug fix in the maintenance stream started from
N,
then its version number will be 2.4.9.
-cut-
In our case, the development stream (N+1 = 2.0) is in HEAD, the
maintenance stream is in R1_0_maintenance branch.
Am I missing something?
Best regards,
Max
Anthony Hunter wrote:
Hi All,
A quick note as per
http://wiki.eclipse.org/index.php/Version_Numbering
<http://wiki.eclipse.org/index.php/Version_Numbering>
<http://wiki.eclipse.org/index.php/Version_Numbering>
<http://wiki.eclipse.org/index.php/Version_Numbering>
Second development stream
- 1.0.100 (indicates a bug fix)
We have been changing the MANIFEST.MF to 1.0.100.qualifier
in
plug-ins we
fix a bug in.
Cheers...
Anthony
Richard
Gronback
<richard.gronback
@borland.com>
To
Sent by:
"GMF
Project developer
gmf-dev-bounces@e
discussions."
clipse.org
<gmf-dev@xxxxxxxxxxx>,
GMF
Release
List
<gmf-releng@xxxxxxxxxxx>
cc
06/29/2006
06:13
PM
Subject
Re:
[gmf-dev] CVS: GMF release
state
tagged, maintenance
branch
Please
respond to is created
"GMF
Project
developer
discussions."
<gmf-dev@eclipse.
org>
Thanks, Max.
Everyone should read and understand this document
regarding
versioning,
paying particular attention to the service segment
guidelines:
http://wiki.eclipse.org/index.php/Version_Numbering
<http://wiki.eclipse.org/index.php/Version_Numbering>
<http://wiki.eclipse.org/index.php/Version_Numbering>
<http://wiki.eclipse.org/index.php/Version_Numbering>
Basically, no API breakage, new APIs or features,
visible changes,
etc. can
be made. Only bug fixes.
The Callisto maintenance stream was a topic at the
Planning Council
meeting
this week, we agreed to target 1.0.1 and 1.0.2 releases
to be
coincident
with Callisto's. The exact dates will be published,
and should align
with
normal platform maintenance releases at end-September
and Q107.
Thanks everyone,
Rich
On 6/29/06 1:01 PM, "Max Feldman" <mfeldman@xxxxxxxxxxx>
wrote:
Hello team,
- org.eclipse.gmf project
release state is tagged with "R1_0"
in CVS;
- new branch "R1_0_maintenance"
is created for the
maintenance dev
stream.
Best regards,
Max
_______________________________________________
gmf-dev mailing list
gmf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gmf-dev
--
Richard C. Gronback
Borland Software Corporation
richard.gronback@xxxxxxxxxxx
+1 860 227 9215
_______________________________________________
gmf-dev mailing list
gmf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gmf-dev
_______________________________________________
gmf-dev mailing list
gmf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gmf-dev
_______________________________________________
gmf-dev mailing list
gmf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gmf-dev
_______________________________________________
gmf-dev mailing list
gmf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gmf-dev
_______________________________________________
gmf-dev mailing list
gmf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gmf-dev
--
Richard C. Gronback
Borland Software Corporation
richard.gronback@xxxxxxxxxxx
+1 860 227 9215_______________________________________________
gmf-dev mailing list
gmf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gmf-dev
_______________________________________________
gmf-dev mailing list
gmf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gmf-dev
|
