Each change package is assumed to be installed in production (and change its status to INS/BAS) some day. The date entered during package creation is the actual planned install date. But with package update (U7) you can change it again, typically to shift the date to some other (later) date. The idea of that is that it allows you to change your initially planned date (during package create) to somewhere later on. Because while the package content is being developed, it turns out that the date that was originally scheduled is too early. So far no problem ...

However, it turns out that over time, for some packages the planned install date keeps shifting (to the future), over and over again. Some samples of this even have a package CREATION date (which cannot be changed!) that are from a few years ago (1 sample is even from about a decade ago).

If you then start to hunt for such packages (= ask the developers of those packages why the install date keeps shifting to the future, instead of making the package BAS at some point), it always goes back to the very same issue: such packages contain components that are actually used in combination with one of more promotion (test) environments, and they should never (repeat: never) be installed in production. So there you are: a package with updated components (= changed as compared to production/baseline). But isn't the purpose of a package to contain changes to be applied to production (and not to manage some test environment)?

Of course there are situations where such differences between test environments and production environments really make sense (debugging options turned on in test, but not in production). But those differences should be somehow included in the coding of those components, which should be archived in an actual baseline library also.

Consider the approach to address this issue as documented in the Z-Clues (login required).