Discussion of Backwards Compatibility for Apache Fineract Maturity Evaluation

[Ed Cable <ed...@mifos.org>]

Hi all,

I"m going to start a couple different threads so we can gather additional
feedback and discuss how we can improve on some of the areas of our Apache
Fineract evaluation.

In this thread I wanted to discuss backwards compatibility.

Criteria for QU40: *The project puts a high priority on backwards
compatibility and aims to document any incompatible changes and provide
tools and documentation to help users transition to new features.*

Sander's Evaluation: Insufficient, while we have structures in place that
would support versioning of API's etc this has not been done at all, and as
such backwards compatibility is not great, this is also not helped by not
clearly stating which breaking changes are part of a given release.

Sander, could you elaborate with more specifics so that Nazeer, Adi and
others can identify how these concerns can be addressed.

Ed



-- 
*Ed Cable*
Director of Community Programs, Mifos Initiative
edcable@mifos.org | Skype: edcable | Mobile: +1.484.477.8649

*Collectively Creating a World of 3 Billion Maries | *http://mifos.org
<http://facebook.com/mifos>  <http://www.twitter.com/mifos>

Re: Discussion of Backwards Compatibility for Apache Fineract Maturity Evaluation

[Sander van der Heyden <sa...@musonisystem.com>]

Hi Ed,

I think all devs already know this, but it basically comes down to the way
new functionality is introduced in the API, in the current way we add
mandatory parameters, or make them dependent on each other between
versions. If a user then upgrades and tries to just run the same API calls
he or she will get errors thrown back. This is where one would normally
ensure new params are non mandatory and always complementary to previous
functionality instead of mandatory. This is a bit of extra work and
therefore frequently skipped.

The other alternative is the api versioning we have but have not actually
implemented in any way, where you could create a v1.1 or something similar
of the API that contains the 'breaking' calls, users ready to switch or in
need of the new feature use it, others stick on the other one.

Thanks,
Sander





Sander van der Heyden

CTO Musoni Services




Mobile (NL): +31 (0)6 14239505
Skype: s.vdheyden
Website: musonisystem.com
Follow us on Twitter!  <https://twitter.com/musonimfi>
Postal address: Hillegomstraat 12-14, office 0.09, 1058 LS, Amsterdam,
The Netherlands

On 12 January 2017 at 20:16, Ed Cable <ed...@mifos.org> wrote:

> Hi all,
>
> I"m going to start a couple different threads so we can gather additional
> feedback and discuss how we can improve on some of the areas of our Apache
> Fineract evaluation.
>
> In this thread I wanted to discuss backwards compatibility.
>
> Criteria for QU40: *The project puts a high priority on backwards
> compatibility and aims to document any incompatible changes and provide
> tools and documentation to help users transition to new features.*
>
> Sander's Evaluation: Insufficient, while we have structures in place that
> would support versioning of API's etc this has not been done at all, and as
> such backwards compatibility is not great, this is also not helped by not
> clearly stating which breaking changes are part of a given release.
>
> Sander, could you elaborate with more specifics so that Nazeer, Adi and
> others can identify how these concerns can be addressed.
>
> Ed
>
>
>
> --
> *Ed Cable*
> Director of Community Programs, Mifos Initiative
> edcable@mifos.org | Skype: edcable | Mobile: +1.484.477.8649
>
> *Collectively Creating a World of 3 Billion Maries | *http://mifos.org
> <http://facebook.com/mifos>  <http://www.twitter.com/mifos>
>