Hello,
Am 11.02.2011 12:53, schrieb Gabor Szabo: > On Fri, Feb 11, 2011 at 11:50 AM, Zeno Gantner<zeno.gant...@gmail.com> wrote: >> Hello, >> >> I saw some discussion about adding new features to Padre on IRC. >> >> Padre is of course not complete yet, but it seems now to be in a state >> where at least some people would like to have rather stable releases, >> which may end up being packaged for Linux distributions etc. >> So it is quite natural to be a bit more conservative about adding new >> and possibly incomplete features, because they could somehow damage >> the appearance of Padre as a stable product. >> >> Of course, nobody should be prevented from developing new features for >> Padre, nor should users be prevented from using them if they want. The frozen release branch may solve parts of the "stable release" request. >> >> So here is my suggestion: If possible (from an architecture point of >> view), develop a feature first in a plug-in. >> If the feature turns out to work nicely, makes sense as a core >> feature, and has matured a bit, we can move it to the Padre core. >> >> Of course, people need to know about such features so that they can >> try them out. >> Here I see two possible solutions: >> 1. Authors of new features advertise their plugins, and it would be >> nice to even mention the experimental feature plugins in Padre release >> announcements and in the Padre docs. >> 2. There is no need for creating a new plugin for each feature, so >> possibly a plugin called Padre::Plugin::ExperimentalFeatures (or >> whatever nice name you come up with) would suffice. >> >> What do you think? I don't see people installing Plugins. Things like "svn" and "tidy" and other mandatory issues are installed, but many others are very unknown to Padre users. Option #2 sounds best to me. The Padre::Plugin::Experimental(Features) should be a core plugin. It could be enabled by default when running trunk and disabled by default when running a released version. > 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. Most plugins are made by busy spare time developers, what about 2 month for each step for major changes? Minor updates could stay in step 1 for a long time (maybe until they block or break something in core). > > 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. Tweaks could be catched by the manual tests and the frozen release branch. We need less released bugs, but we shouldn't make development too complicated. > > regards > Gabor _______________________________________________ Padre-dev mailing list Padre-dev@perlide.org http://mail.perlide.org/mailman/listinfo/padre-dev
