cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <>
Subject Re: How to release plugins & platforms lock-step
Date Wed, 11 Sep 2013 17:32:44 GMT
I think we'll be fine if we:

1 - make sure things always work on HEAD (master for non-plugins, dev for
2 - Make sure the latest plugin versions always work (don't update platform
repos if the update will break existing plugin versions)
3 - We leave a bit of time for people to update their plugins before
deleting deprecated things from platforms

On Wed, Sep 11, 2013 at 12:59 PM, Michal Mocny <> wrote:

> (This is motivated by the recent issue with DirectoryManager on Android,
> but I didn't want to fork that thread)
> Because we are using separate git repos, and even worse, releasing at
> different time intervals, it is going to be difficult to make any changes
> that require lock-step changes to platform & plugin - such as changing any
> public method signature, moving code around between the boundaries, etc.
> One strategy is to do 3 (sometimes even need 4) patches instead of 2, each
> one being a small step forward and compatible with all previous steps:
> - Patch (A) to lay the groundwork for some future work in (B), and bump the
> version MINOR
>   - This version of (A) should be both backwards or forwards compatible
> with versions of (B)
>   - This can often be difficult, such as supporting various function
> signatures at the same time without changing namespaces etc.
> - Patch (B) with your feature, taking advantage of (A)'s groundwork above.
> Bump the version MAJOR, and the version dependency on (A)
> - Patch (A) to remove/deprecate the old code, bump the version number
> again, this time with a MAJOR
> ( The fourth patch is sometimes a necessity to lay groundwork in (B) before
> you can lay groundwork in (A) )
> I've had to do this on projects before, and its really not fun.
> Another option, is to leverage version dependencies with a little
> speculative planning:
> - Patch (A) and (B) in one patch, bump the MAJOR and update dependencies
> (this is basically what Andrew tried to do)
> The issue is that (A) and (B) aren't released to the world at the same
> time, so you have to speculatively bump version dependencies for
> platform/plugin which may not be released yet.  This *requires* a plugin
> repository which can supports version deps, which we don't have right now.
>  Until then, we should stick to the first strategy (actually for now all
> plugins must work with 3.0.0 I think because of plugman repository?).
> Any other thoughts/suggestions, aside from "just don't change anything"?
> -Michal

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message