Hi, On Fri, Feb 11, 2011 at 12:53 PM, 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.
I agree that the solution is incomplete. I only thought of things that are already easy to implement as plugins now. Other than that, if we add complicated rules about API changes etc., we may be better served with one or several experimental branches (possibly using git) and that's it. Best regards, Z. -- MyMediaLite Recommender System Library: http://ismll.de/mymedialite _______________________________________________ Padre-dev mailing list Padre-dev@perlide.org http://mail.perlide.org/mailman/listinfo/padre-dev
