Confirmed.
Regards,
Max
Frederic Plante wrote:
Hi Rich,
The version naming strategy is new
to
everybody, including platform... It is time to innovate ;-). Also I
don't
think what's proposed is contrary to the Eclipse document nor complex.
That said, given a hotfix for 1.0.0
would be surprising and given you and I have better things to do than
entertain
the readers of this mailing list, ;-) the runtime team will revert
back to 1.0.1 for now.
Please confirm the minimal plug-in
version
number increment for plug-ins modified in HEAD (GMF "2.0.0" work)
will be + 0.0.100
Thanks
- Fred
_________________________________
Frédéric Plante
Rational Software, IBM Software Group
Hi Fred,
The important point you make is that it¹s the first time we¹re doing
this.
Given that other projects at Eclipse have been doing this for much
longer,
and with great success, perhaps we should look to their lead as the
example?
How does the platform, EMF, WTP, etc. do it today? Do they support
the OEhot
fix¹ concept? Call me conservative, but I¹d prefer to stick with
the
simplest approach possible and to the advice of the versioning document
(as
I understand it) and see others practicing today.
If a client really needs a fix, they have full access to CVS and our
build
procedure and are welcome to create whatever patch they¹d like and give
it
whatever version # they¹d like, right?
With that, the qualifier remains distinctive and can be used for just
this
purpose, as I understand it.
Best,
Rich
On 7/17/06 2:45 PM, "Frederic Plante" <fplante@xxxxxxxxxx>
wrote:
>
> Hi Rich,
>
> The problem with M-Builds is that they cumulate all the fixes;
which
increases
> the risk for clients. The idea of hotfixes is to deliver the
strict
minimum
> required to unblock clients.
>
> I understand that for 1.0 the likelihood of a hotfix is low, but
given
we are
> doing this exercise for the first time we may as well set the tone
properly.
> Also, the cost of protecting ourself from being "version squeezed"
is null.
>
> 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 02:36 PM
> 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,
>
> I guess I was recalling an earlier email regarding our development
plan,
> when I proposed to align with our maintenance releases with
Callisto.
As I
> recall, the proposal was to have those who require ³hot fixes² to
simply
> leverage our interim M-builds and depend on the qualifier to
distinguish.
> Does this not work, and am I missing something?
>
> I suspect that by the time most clients adopt GMF 1.0 and we get
asked
for a
> hotfix, 1.0.1 will be out. ;)
>
> Best,
> Rich
>
>
> On 7/17/06 11:40 AM, "Frederic Plante" <fplante@xxxxxxxxxx>
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.
>> >
>> > 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?
>> >
>> >
>> > 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:56 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
>> >
>> >
>> >
>> >
>> > 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
>> > 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,
>> >
>> > 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>
>> > <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>
>> >
<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>
>> >
<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
|