> We have plugins which doesn’t expose any APIs Then why do we track version numbers for such plugins?
Vratko. From: Damjan Marion <dmar...@me.com> Sent: Monday, 2019-May-27 13:56 To: Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) <vrpo...@cisco.com> Cc: Paul Vinciguerra <pvi...@vinciconsulting.com>; vpp-dev@lists.fd.io Subject: Re: [vpp-dev] Plugin Versions On 27 May 2019, at 13:54, Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) via Lists.Fd.Io <vrpolak=cisco....@lists.fd.io<mailto:vrpolak=cisco....@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 that fixes incorrect behavior. That means API version should be bumped even if the change only affects the implementation (and not API definition itself). In principle, if there is an internal change which has not fixed any incorrect behavior, SemVer says you are not required to bump the patch version. > multiple version of plugins can provide exact same binary API That could happen when the plugin undergoes such an internal change that does not affect behavior at all (at least not positively). Do you have a realistic example of that? All I can think of is renaming a variable, or similar silly examples. Either way, I think it is safe to assume that any plugin version bump can have at least some behavior consequence visible to user, so bumping API at the same time is simpler. Alternatively, we can change the plugin versioning scheme to acomodate "invisible" bumps. X.Y.Z.W (Major.Minor.Patch.Internal). BTW We have plugins which doesn’t expose any APIs, by design….
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13156): https://lists.fd.io/g/vpp-dev/message/13156 Mute This Topic: https://lists.fd.io/mt/31757481/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
