ke pass in a associative array of modules +
> required versions, and get a yes/no reply back.
>
> Best regards,
> Ole
>
>
> >
> > From: on behalf of "Marek Gradzki -X
> > (mgradzki - PANTHEON TECHNOLOGIES at Cisco)"
> > Date: Thursday, October 5, 20
n a associative array of
> modules + required versions, and get a yes/no reply back.
>
> Best regards,
> Ole
>
>
> >
> > From: on behalf of "Marek Gradzki -X
> (mgradzki - PANTHEON TECHNOLOGIES at Cisco)"
> > Date: Thursday, October 5, 2017 at 4
+
required versions, and get a yes/no reply back.
Best regards,
Ole
>
> From: on behalf of "Marek Gradzki -X (mgradzki
> - PANTHEON TECHNOLOGIES at Cisco)"
> Date: Thursday, October 5, 2017 at 4:38 AM
> To: Ole Troan , vpp-dev
> Subject: Re: [vpp-dev] API version
Cisco)"
Date: Thursday, October 5, 2017 at 4:38 AM
To: Ole Troan , vpp-dev
Subject: Re: [vpp-dev] API versioning
+1
having explicit version number in the api file is a good thing in my opinion.
I think also Java bindings could benefit a bit from your proposal.
While the only backward compatible
.
Regards,
Marek
-Original Message-
From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On
Behalf Of Ole Troan
Sent: 2 października 2017 14:37
To: vpp-dev
Subject: [vpp-dev] API versioning
All,
I have received a few suggestions that especially the dynamic language
All,
I have received a few suggestions that especially the dynamic language bindings
(Python, Lua) would benefit from a better versioning system than depending and
storing the CRC values of each VPP API message.
Could you please take a look at the proposal for semantic versioning of API
module
