Hi Andrei The discussion wrt to making the upcoming release Oak 2.0 is not about backwards compatibility (or making any kind of statement about this) but rather to highlight the fact that we modularised Oak and by such allow us to change the release model from all-in-one to independent releases of the individual modules.
On the other hand backwards compatibility in terms of semantic versioning is defined by the package exports statements and has nothing to do with the release number of Oak. So irrespective on whether this is going to be Oak 1.8 or 2.0: from a semantic versioning point of view we increased a bunch of minor versions (as Oak mostly contains provider types) and afaik one major version increase (see OAK-6318 and OAK-6319 for all the details). As discussed earlier exported packages that don't specify an export version are considered internal and are not subject to semantic versioning contracts. Hope that helps Angela On 17/10/17 09:28, "Andrei Kalfas" <[email protected]> wrote: >Hi Angela, > >I used semantic versioning just to get a definition of versioning, I >guess that the question should have been: > >Will oak 2.0 be backward compatible with oak 1.6 ? > >Thanks, >Andrei > >> On Oct 17, 2017, at 10:23 AM, Angela Schreiber >><[email protected]> wrote: >> >> hi andrei >> >> this has nothing to do with semantic versioning >> >> regards >> angela >> >> From: Andrei Kalfas >><[email protected]<mailto:[email protected]>> >> Reply-To: >><[email protected]<mailto:[email protected]>> >> Date: Tuesday 17 October 2017 09:18 >> To: >>"[email protected]<mailto:[email protected]>" >><[email protected]<mailto:[email protected]>> >> Subject: Re: Consider making Oak 1.8 an Oak 2.0 >> >> Hi, >> >> 2.0 as in semantic versioning [1] is not backward compatible with 1.x. >> >> Will it be the case ? >> >> Thanks, >> Andrei >> >> >> [1] >>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsemver.or >>g%2F&data=02%7C01%7C%7C5002b2ab30c3456277cd08d5152ff041%7Cfa7b1b5a7b34438 >>794aed2c178decee1%7C0%7C0%7C636438217997390545&sdata=3viXWNgw0jwVU62Zeuqz >>u6T4%2BXJi6UKmxpG52SuJjUY%3D&reserved=0 >> >> On Oct 17, 2017, at 10:13 AM, Angela Schreiber >><[email protected]<mailto:[email protected]>> wrote: >> >> Hi Davide >> >> Sure... I already started doing so and there is a dedicated JIRA ticket >> for that matter. >> Feel free to contribute if you spot something that is missing or >> misleading. >> >> Angela >> >> On 16/10/17 13:36, "Davide Giannella" >><[email protected]<mailto:[email protected]>> wrote: >> >> On 13/10/2017 16:01, Matt Ryan wrote: >> Makes good sense to me. Cutting the next release as a major version >> reflects the high amount of change in dependencies that the downstream >> should expect. >> >> +1. >> >> I think we should as well document somewhere in oak-doc the new bundles >> or where a code has migrated so that an upgrading consumer may find it >> easier to move between 1.6 and 2.0. >> >> D. >> >> >> >> >
