Re: [gmf-dev] CVS: GMF release state tagged, maintenance branch is creat

[Frederic Plante <fplante@xxxxxxxxxx>]

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