A little but not worth the risk of breakage due to the version of plugins and code not being in sync. ^^
wvengen [via foodsoft] schreef:
> Good points.
> Regarding API compatibility - and I hope to introduce tests for plugins
> at some point.
> The commit log of foodsoft would be cleaner if it wasn't cluttered with
> commits for plugins. That's the most important reason I can think of not
> wanting to have it in-tree. Does that make sense?
> - Willem
> On 07-11-13 18:37, mathijs [via foodsoft] wrote:
>> Start out with the 1st option (a plugins folder) and then move to
>> another option when necessity arises. Some use cases:
>> - Perhaps some user wants to use foodsoft plugins in other applications
>> (highly unlikely).
>> - Could be that people running a newer or older release of the software
>> want to backport plugins. This requires API compatibility and requires
>> plugins to be well tested for this compatibility.
>> AFAIK, both of the above scenario's are not too realistic in the
>> forseeable feature - but I might have missed something.
> If you reply to this email, your message will be added to the discussion below:
> To start a new topic under foodsoft-dev, email [hidden email]
> To unsubscribe from foodsoft-dev, visit