[
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 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
