>> Sorry. Let me try again.
>>
>> The semver definition seems to say that backend changes that don't change
>> the API, still should have the patch version increased.
>> Bug fixes not affecting the API increment the patch version
>> New features would either be backward compatible with the API or
> We have plugins which doesn’t expose any APIs
Then why do we track version numbers for such plugins?
Vratko.
From: Damjan Marion
Sent: Monday, 2019-May-27 13:56
To: Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco)
Cc: Paul Vinciguerra ; vpp-dev@lists.fd.io
Subject: Re: [vpp-
> On 27 May 2019, at 13:54, Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at
> Cisco) via Lists.Fd.Io wrote:
>
> SemVer says:
> > Patch version Z (x.y.Z | x > 0) MUST be incremented if only backwards
> > compatible bug fixes are introduced.
> > A bug fix is defined as an internal change th
nt: Saturday, 2019-May-25 19:46
To: Paul Vinciguerra
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Plugin Versions
On 25 May 2019, at 18:42, Paul Vinciguerra
mailto:pvi...@vinciconsulting.com>> wrote:
Sorry. Let me try again.
The semver definition seems to say that backend changes th
> On 25 May 2019, at 18:42, Paul Vinciguerra wrote:
>
> Sorry. Let me try again.
>
> The semver definition seems to say that backend changes that don't change the
> API, still should have the patch version increased.
> Bug fixes not affecting the API increment the patch version
> New features
Sorry. Let me try again.
The semver definition seems to say that backend changes that don't change
the API, still should have the patch version increased.
> Bug fixes not affecting the API increment the patch version
New features would either be backward compatible with the API or not,
therefore
> On 25 May 2019, at 13:43, Paul Vinciguerra wrote:
>
> Hi Damian,
>
> That's what I initially thought as well. The semver doc says:
> For this system to work, you first need to declare a public API. This may
> consist of documentation or be enforced by the code itself. Regardless, it is
>
Hi Damian,
That's what I initially thought as well. The semver doc says:
>
> For this system to work, you first need to declare a public API. This may
> consist of documentation or be enforced by the code itself. Regardless, it
> is important that this API be clear and precise. Once you identi
if plugin code didn’t change there is no reason to bump api version, on other
side plugin version needs to change as it is linked against different core
libraries….
> On 25 May 2019, at 03:57, Paul Vinciguerra wrote:
>
> Is there any reason for having plugin versions that are distinct from t
