On Fri, May 08, 2015 at 09:48:39AM -0400, Mike Holmes wrote: > On 8 May 2015 at 09:37, Stuart Haslam <[email protected]> wrote: > > > On Fri, May 08, 2015 at 08:40:39AM -0400, Mike Holmes wrote: > > > sorry paste failed me insert odp_version_impl_str > > > > > > However we just re-purposed odp_version_impl_str from returning that "1" > > > to a string that is good for debug logs. > > > > > > odp_version_impl_str = 0 << revert this to its old purpose > > > > Wouldn't it make sense for this function to return a string that > > matches the name of the tag that gets applied for releases that change > > the implementation and not the API?.. surely that won't be "0" > > > > We did start with this solution concatenating the api number and an > implementation number only. For this next release it would be 1.1.0.0 and > the tag in the repo should be v1.1.0.0 so I think you are suggesting the > original proposal. For a non API change if it happened right after 1.1 it > becomes 1.1.0.1
Actually I didn't really know what to suggest so I was just asking a question :).. point is that the implementation version string should actually be useful for both tracking down where the release originated from (git tag) and using in bug reports (dropdown box in bugzilla). I think just appending it to the API version is going be confusing (it already is), but given that we can't make API and implementation releases independently perhaps it's still the best thing to do. Still not clear on how tags would be applied though, would both API version and implementation version tags be applied for releases that change both? -- Stuart. _______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
