This regression is likely related to Ed's (assignee) changes to put artefact deployment under sstate control. Previously one could `bitbake my-image && bitbake my-image` and get two versions of the image built and deployed to DEPLOY_DIR_IMAGE. With current HEAD of master & morty a previous image artefact will be deleted before the new one is deployed. We assume nobody has noticed this behaviour before now because many of us use RM_OLD_IMAGE during development. It would be great to add a test to validate the expected behaviour (perhaps as a separate bug to be handled in 2.3).
It's arguable that this behaviour change is desirable. If so we we should document it in the release notes and migration guide and remove RM_OLD_IMAGE. Otherwise we should fix this regression before the 2.2 release. I've sent an RFC to the openembedded-architecture list: http://lists.openembedded.org/pipermail/openembedded-architecture/2016-October/000260.html
Initial feedback to the RFC seems to be in favour of keeping the new behaviour, so I've submitted patches to remove RM_OLD_IMAGE from OE-Core, et al: http://lists.openembedded.org/pipermail/openembedded-core/2016-October/127532.html http://lists.openembedded.org/pipermail/openembedded-core/2016-October/127533.html https://lists.yoctoproject.org/pipermail/yocto/2016-October/032427.html https://lists.yoctoproject.org/pipermail/poky/2016-October/010750.html
Update: the first patch in the series to actually remove all mentions of RM_OLD_IMAGE has been merged, the patches for documentation and local.conf have not.
ref-manual patch has also been merged. Only the local.conf.sample changes are outstanding.
Patches are merged.