How to release plugins & platforms lock-step

[Michal Mocny <mm...@google.com>]

(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

Re: How to release plugins & platforms lock-step

[Andrew Grieve <ag...@chromium.org>]

I think we'll be fine if we:

1 - make sure things always work on HEAD (master for non-plugins, dev for
plugins)
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 <mm...@google.com> 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
>