[dev] Strategy for backward compatibility

[Samuel Chong <sa...@gmail.com>]

hi,

I have been thinking about best approach to support backward compatibility.
What's your opinion? I would like to learn from you if you have a working
approach or you know of a good strategy.

I had been thinking the two approach as below. but, they are less than
ideal.
Option 1: Create a driver internally for each version.
                Pros:
                     Use to choose which version to use.
                     Upgrade is by choice.
                     Retire old version easily and cleanly
                     User could specify which version of the driver they
want to use.

                Cons:
                      A lot of duplication in code.
                      Bug fixing become cumbersome across multiple versions

Option 2: Standardise the data structure for all version.
                approach: Make the new argument optional. Ignore old
argument that is no longer required.Hide deplecated argument in kwargs.

                Pros: Upgrade is seemless

                Cons:
                        Handle multiple scenarios to cater for backward
                            compatibility. if version x, do this; if
version Y, do that....
                        It will only works only if new property is optional
in request. Removal of a mandatory property will be problematic.
                        One could easily get lost in the data structure
corresponding to each version


Cheers,
Sam

Re: [dev] Strategy for backward compatibility

[Samuel Marks <sa...@gmail.com>]

I'm thinking to go further and have schema files for each version and
transformation [compilation] rules to map changes across.

We could start with something simple like JSON-schema:

{ "title": "Azure schema",
"type": "object", "version": "1.0.1",
"properties": {"subscription_id: {"type": "string"} },
"required": "subscription_id"}

(we can also do inheritance for base Compute driver rules)

Then move onto JSON-patch for the transformations.

Now you don't need to go as far as all that, but you can get to the point
where suggestions are emitted "you're using version 3 of the schema but
version 4 of the library, change `subscription_id` to `ex_subscription_id`
to proceed".

Clearly this keeps things generic, and enables independent evolvability of
modules.

You can choose a more Pythonic approach and serialise this idea into Python
classes with strict schema rules per config type, that are then validated
using some validating Python library.

Pretend this is an ORM and it'll all make sense!

Just my 2¢,

Samuel Marks
http://linkedin.com/in/samuelmarks

On Wed, Nov 2, 2016 at 5:24 PM, Samuel Chong <sa...@gmail.com> wrote:

> hi,
>
> I have been thinking about best approach to support backward compatibility.
> What's your opinion? I would like to learn from you if you have a working
> approach or you know of a good strategy.
>
> I had been thinking the two approach as below. but, they are less than
> ideal.
> Option 1: Create a driver internally for each version.
>                 Pros:
>                      Use to choose which version to use.
>                      Upgrade is by choice.
>                      Retire old version easily and cleanly
>                      User could specify which version of the driver they
> want to use.
>
>                 Cons:
>                       A lot of duplication in code.
>                       Bug fixing become cumbersome across multiple versions
>
> Option 2: Standardise the data structure for all version.
>                 approach: Make the new argument optional. Ignore old
> argument that is no longer required.Hide deplecated argument in kwargs.
>
>                 Pros: Upgrade is seemless
>
>                 Cons:
>                         Handle multiple scenarios to cater for backward
>                             compatibility. if version x, do this; if
> version Y, do that....
>                         It will only works only if new property is optional
> in request. Removal of a mandatory property will be problematic.
>                         One could easily get lost in the data structure
> corresponding to each version
>
>
> Cheers,
> Sam
>