Copying this in from a thread in the #core-plans channel on Slack:
After working on some plans over the last week and referencing the Arch Linux packages I’m remembering a feeling I had working through this the first time (might not be accurate anymore, who knows): I feel like Habitat packages could be thought of as a “rolling release”-style distribution, much like Arch Linux, NixOS, maybe even Gentoo to an extent. For the default case, we’d strongly encourage everyone to use the latest releases where that’s possible. With the frame, when I think about the Docker package in particular I don’t see a ton of value to keeping an older release around longer than it needs to be. The community around Docker tends to value the latest as well (that’s where the features and bugfixes and tool compatibility live) so I suspect that the number of folks using an older version of Docker becomes very tiny very fast. It’s not even terribly difficult to copy our core plan, pin it back and publish your own <myorigin>/dockerVX package to keep a certain version around. Now, in the case of another package such as Python, Ruby, etc., there does seem to be a case for having older versions rebuilt (to a point) as some of the application support moves a bit slower and may take longer to transition forward. This might be in part why we hadn’t written anything formal down–it fell into the “it depends” camp. Not always the best, but I’ve been treating our core-plans with a “latest if possible and sometimes have older versions” attitude. Problem is, I forgot why 
How does that strike folks? Helpful? Do you agree or disagree? Could this help inform how we might deal with older versions of software?