[
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 Rich,
I agree with you. GMF should present itself to the community as *one*
project or framework. This implies that no partial releases of sub
components are released and distributed independently and parallel to
the GMF project as a whole.
So, if there is a need for clients of the runtime to be provided with
hot fixes in addition to the regular maintenance builds, these should be
provided for the whole project (runtime+tooling).
I'm convinced that the unified release of all sub components is worth
the extra work (and complexity of the build infrastructure).
Kind regards,
Henrik
Richard Gronback wrote:
> 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@xxxxxx.com_
> <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>
>
> 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>
>
> 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
>
--
..................................................
Dr. Henrik Rentz-Reichert mailto://hrr@xxxxxxxxx
Hafnerstr. 1 fon +49-7533-9342-43
D-78476 Allensbach fax -44
