[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [dsdp-pmc] API freeze
- From: "Oberhuber, Martin" <Martin.Oberhuber@xxxxxxxxxxxxx>
- Date: Tue, 22 Apr 2008 10:46:58 +0200
- Delivered-to: email@example.com
- Thread-index: Acij3T1sSVaoAVk1QQmlrKZMlgLxJQAb2Log
- Thread-topic: [dsdp-pmc] API freeze
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
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
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?
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
> -----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?
> dsdp-pmc mailing list