Ideally a specific revision of a layer should specify on which revision it depends on/was tested with, so people can reproduce that same setup.
Randomly mixing revisions is a recipe for problems. Expecting that a layer informs its users that something is changing is probably not workable. How would a layer maintainer know what layers are actually depending on it (especially for things like oe-core)? If one is using the head of a layer one is living on the bleeding edge (and hence sometimes one bleeds) (and doing production work based on that seems unwise). Then again, I seem to recall that somewhere in the spring we agreed on a deprecation policy where "high impact changes" like for toolchain would be done like: - commit new version - wait a while (2 weeks?) - remove old version thus giving people a chance to migrate. Frans. (PS: of course it is also possible to proceed in a perfectly synchronised lockstep, but that probably requires some central coordination and some staging trees or so to test against before the lockstep is performed)
_______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core