Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [gmf-dev] CVS: GMF release state tagged, maintenance branch is created

Hi Max,

Unfortunately there is nothing worth the term "vision" here. A "hotfix" is simply a minimalist update to a component to solve a critical issue. Projects can create streams and branches as they see fit, no need for an Eclipse community group hug here :-) If a project wants to create a maintenance stream in case of emergencies that's their choice.

 I am not sure I understand the second comment, sorry if I interpret wrong. If a plug-in had no "visible"changes since "GMF 1.0" when we release "GMF 2.0", it will still be 1.0.x . Nothing prevents us from using 1.0.1000 for new "invisible" work for "GMF 2.0.0". That would leave us plenty of room for maintenance. :-)

    Thanks

       - Fred

_________________________________
Frédéric Plante
Rational Software, IBM Software Group


Max Feldman <max.feldman@xxxxxxxxxxx>
Sent by: gmf-dev-bounces@xxxxxxxxxxx

07/17/2006 01:02 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,

 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
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>
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
 
_______________________________________________
gmf-dev mailing list
gmf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gmf-dev

Back to the top