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

Reply via email to