Great points Tom. We discussed this again in the Equinox team call this morning.
The need to talk openly about API changes is two-fold: 1) The community needs to be aware of what is coming or proposed. We need their feedback and input. Perhaps they are depending heavily on something that is about to change? Perhaps they really need the change? We need to know. 2) Sober second thought. Writing out the API change request message gives you a moment to think about the changes, are they really needed, how will they affect people, who is benefitting and how, ... By seeking approval from the broader community and project leadership you get constructive feedback on the ideas and perhaps a broader perspective. So to that end, please 1) read Tom's guidelines below 2) review any open bugs that have the "api" keyword and is for 3.6. If it is still valid, write up a API change request message outlining the risks etc. See http://dev.eclipse.org/mhonarc/lists/eclipse-pmc/msg01009.html for an example of a clearly stated/structured change request. The message should be sent to the equinox-dev or p2-dev list as appropriate. If the bug is no longer valid or is to be deferred, either remove the keyword or change the milestone to something not related to 3.6. Thanks Jeff/Tom On 2010-03-24, at 1:12 PM, Thomas Watson wrote: > I sent a similar note out on Monday on this same topic. We must have PMC > approval for all API changes that go in after API freeze. There is an API > freeze for a reason. The community needs to stabilize on our M6 (API freeze) > build. Any API changes at all (even additions) need to be carefully > considered and if at all possible deferred until the next release. Any API > changes this late in the cycle can be very disruptive to our a adopters and > consumers. > > If API changes are a must then please ensure the following steps are taken. > > 1) Post a message to p2-dev mailing list describing the API change, its > benefits and and the potential risks (who it breaks, any known clients etc.). > If it turns out that the are already a number of clients of the API that is > changing within Helios or with in the Eclipse community then we likely need > to avoid the change. Any changes that could break a client also must be > posted to the cross-project mailing list to make the community aware of the > breaking change. > > 2) Make sure a bug is open to track the API change. > > 3) Ask for PMC approval on the bug. This is done in a similar way to asking > for a patch review on the bug report. There is a section to ask for PMC > approval. You must get a +1 from Jeff or myself before releasing the change > to CVS. > > Please speak up if you have any questions or doubts at all. > > Tom > > _______________________________________________ > p2-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
