Mailing-List: contact dev-help@fineract.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@fineract.incubator.apache.org
MIME-Version: 1.0
In-Reply-To: <CAPnWRThZ+6UcL9pLsLgiM1je=v0AP1XTBdPkcfFh2zjSXY2+Vg@mail.gmail.com>
References: <CAPnWRThZ+6UcL9pLsLgiM1je=v0AP1XTBdPkcfFh2zjSXY2+Vg@mail.gmail.com>
From: Sander van der Heyden <sandervanderheyden@musonisystem.com>
Date: Mon, 16 Jan 2017 07:46:01 +0100
Message-ID: <CAKEwc2Q3w1NoL+kt8H7f-v+A6P08Sr9EG8N3bifJpeggTvooig@mail.gmail.com>
Subject: Re: Discussion of Backwards Compatibility for Apache Fineract
 Maturity Evaluation
To: dev@fineract.incubator.apache.org
Content-Type: multipart/alternative; boundary=94eb2c03bb669d10a00546308a7b
archived-at: Mon, 16 Jan 2017 06:46:44 -0000

--94eb2c03bb669d10a00546308a7b
Content-Type: text/plain; charset=UTF-8

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 <edcable@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>
>

--94eb2c03bb669d10a00546308a7b--