> >> 2. If public API changed then you need to fix all existence platforms, > >> to not break their compilation/work. > > I changed the reference API and implementation (== linux-generic). > Maintainers of other implementations are free to decide when (and more > importantly who) to follow. We cannot keep all implementations in 100% > sync. It's better to break a build (if they are reusing linux-generic > code), than try to fix all implementations at once (with potentially > untested, buggy code). > > You should not break other platforms when changing api for > linux-generic. You added new flag to odp_shm_reserve() for example to > example/generator/odp_generator.c but ks2 and dpdk still have on one > argument less. So their compilation will fail. And this things have to > be avoided. We also decided that git history > have to be 'git bisect' friendly. That rule is also acceptable on > other arches. Maybe we need to start versioning the API and test apps, so that it's possible to have different implementations out-of-sync. I agree but won't that be for official releases ? If not we need to schedule a point each week/month to get a working set - monthly fits Linaros schedule.
[Petri] Even weekly freeze cycle is too slow. I was thinking that: - every API change increment API version number - we have only one reference API/implementation/test app branch and that's linux-generic - latest development is always in linux-generic (for example API v0.8.12) - other implementations (in the repo) would branch(some version of) the reference, for example - linux-dpdk could be at 0.8.11 (including API and test cases) - linux-k2 could be at 0.7.17 (including API and test cases) Otherwise we have three references implementations (if all must at sync with latest API) and we don't afford that. E.g. if we change the queue API, should we all wait that TI K2 (HW specific) implementation is updated, before the change can be merged? It'd hold back API development and all other guys (also those outside of the repo). Shouldn't this all be easy with git :) -Petri _______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
