Firstly, we already have a clear description of the plugin API, it's fully documented.
Secondly, we already have a fully implemented system for dealing with API breakages. The plugin declares what classes it uses, and the Padre version it was last confirmed to work with for each class. Then the plugin managed compares each declared class to confirm that it falls in between the current $VERSION and the (optional) $COMPATIBLE variables for each class. This way, we only disable plugins that are using a specific API that gets changed. Thirdly, in response to some other people, we ALREADY have a system for experimental core features via the feature_ configuration keys. Config entries beginning with feature_ that are true by default represent features that a number of people don't use and can be disabled to reduce the memory and cognative complexity of Padre. Config keys beginning with feature_ that are false by default represent features that aren't considered finished yet, and you need to turn on manually (one at a time). I think the idea of an experimental plugin represents the worst of both worlds. It's shoved in the core, it's all mixed in together (all or nothing, plus way harder to merge just one feature) and it's duplicating an already existing mechanism for experimental features. Adam K On 11 February 2011 22:53, Gabor Szabo <szab...@gmail.com> wrote: > I agree that developing things first as a plugin would be a good idea. > It might require some improved API for the plugins so they can > do thing which the current API does not let them do yet. > It will also require a clear description of the plugin API and > making sure we don't break the API without proper notification and > a period that allows the plugins to move to the new API. > > That might mean. > 1) Add new API feature and mark old API as deprecated. Release Padre > 2) Wait 2 weeks, then add command line warnings to the deprecated > methods. Release Padre. > 3) After another 2 weeks remove old API. Release Padre > > The periods can be longer if needed and there can be additional Padre > releases in the between. > > > This still does not solve the whole issue though as some of the changes > we want to make are tweaks to existing features. I'll send a separate > message with that. > > > regards > Gabor > _______________________________________________ > Padre-dev mailing list > Padre-dev@perlide.org > http://mail.perlide.org/mailman/listinfo/padre-dev > _______________________________________________ Padre-dev mailing list Padre-dev@perlide.org http://mail.perlide.org/mailman/listinfo/padre-dev
