RE: [dsdp-pmc] API freeze

["Gaff, Doug" <doug.gaff@xxxxxxxxxxxxx>]

This is well put Martin. I don't have anything add on the policy.

Regarding the specific case of a DSF adopter in TM, perhaps you both
should discuss what API change DD needs.

> -----Original Message-----
> From: dsdp-pmc-bounces@xxxxxxxxxxx [mailto:dsdp-pmc-
> bounces@xxxxxxxxxxx] On Behalf Of Oberhuber, Martin
> Sent: Tuesday, April 22, 2008 4:47 AM
> To: DSDP PMC list
> Subject: RE: [dsdp-pmc] API freeze
> 
> Hi Pawel,
> 
> My understanding (other PMC members may correct me)
> Is this, regarding Ganymede participants:
> 
>   * It's up to the projects how they want to treat
>     their ramp-down policies. Only Ganymede requirement
>     is that YOUR project's policy is written down
>     somewhere e.g. on the Wiki - the contents of that
>     policy is totally up to the project.
> 
>   * Projects should decide on a ramp-down policy that's
>     best for their clients / adopters.
> 
> Typically, the more adopters a project has, the earlier
> There should be an API freeze such that the adopters can
> Adjust. That's why Platform is freezing API with M6, also
> To ensure that they are not overrun with API change requests
> After that time and can focus on feature freeze, bug fixes
> And documentation cleanup and the like.
> 
> For TM, last year we had almost no adopters so we changed
> APIs until very late (even RC2 I think).
> 
> This year, TM has many more adopters already so we've been
> Announcing an API freeze with M6; but, it already turned
> out that we had made one "mistake" in the API so we're
> Correcting this (bug
>    https://bugs.eclipse.org/bugs/show_bug.cgi?id=226948
> ).
> 
> In short, our strategy this years is to
>   1.) Avoid breaking API changes after M6, to ensure
>       that adopters can fully code against our APIs by M6
>   2.) Allow non-breaking API changes for M7 when it's
>       due to regressions or very important fixes; but
>       requires review from multiple committers
>   3.) NOT allow any more API changes that would just
>       be there for new features.
> 
> With (3) we try to protect ourselves against API change
> Requests from the Community, which should really have
> Issued those requests earlier. We need to focus on fixing
> Bugs and regressions now, and start cleaning up for the
> Release. Our ramp down plan is at
> http://wiki.eclipse.org/DSDP/TM/3.0_Ramp_down_Plan_for_Ganymede
> 
> Given that we have a DD-DSF adopter in TM (with the
> TCF component), I'd personally appreciate if DD-DSF
> Could avoid breaking API changes after M6 as well
> Though we can discuss this in urgent cases. For any
> Incubating components, or "internal" non-API, I do
> Not see any need for any API freeze at all.
> 
> What do other PMC members think?
> 
> Cheers,
> --
> Martin Oberhuber, Senior Member of Technical Staff, Wind River
> Target Management Project Lead, DSDP PMC Member
> http://www.eclipse.org/dsdp/tm
> 
> 
> 
> > -----Original Message-----
> > From: dsdp-pmc-bounces@xxxxxxxxxxx
> > [mailto:dsdp-pmc-bounces@xxxxxxxxxxx] On Behalf Of Pawel Piech
> > Sent: Montag, 21. April 2008 20:26
> > To: DSDP PMC list
> > Subject: [dsdp-pmc] API freeze
> >
> > Hi All,
> > I would like to get some clarity on what is our policy wrt
> > API feeze?
> > M6 was the API freeze and my intepretation is that following this
> > milestone we have to follow a process to make API changes
> > (even backward
> > compatible once).  Is this process written up anywhere?
> >
> > Thanks
> > Pawel
> > _______________________________________________
> > dsdp-pmc mailing list
> > dsdp-pmc@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/dsdp-pmc
> >
> _______________________________________________
> dsdp-pmc mailing list
> dsdp-pmc@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/dsdp-pmc