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?
Thinking of our package maintenance cycles like those of a rolling distro make a good deal of sense to me. Personally, I’m always going to be in favor of minimizing the maintenance burden involved in keeping the core origin curated and clean so opting to not continue support of certain older packages seems somewhat reasonable.
In the discussion that spawned this there were some other topics covered as well. I’m sure @nellshamrell can add that list here.
It is a rolling release. For me, the big thing we have to start doing is running packages with major version numbers in the name. For example, we shouldn’t have a core/postgresql - rather, it really should be core/postgresql10 and core/postgresql9. This ensures that any breaking changes are taken on purpose, and in the case of mainlines that continue, they get to keep continuing.
My main, immediate question is around when a new edge release is announced. Docker 18 is currently at edge release, while Docker 17 is still the stable release. Should we go ahead and update core/docker to use Docker 18? (after which we would create a core/docker17 plan?).
I’m onboard with restricting naming to major versions (i.e. not have a core/postgresql plan, but core/postgresql10 and core/postgresql9, etc.) but that would need to go through the RFC process for core plans (anyone is welcome to file that, if they like!)
Regarding docker, it may be moot. The stable channel for docker releases ever quarter, whereas edge is monthly. The quarter for a promotion to stable for 18 is coming up pretty soon.
Right now I feel like we have a pretty difficult time tracking even stable software releases. Personally I don’t get warm and fuzzy feelings about starting to try to maintain edge packages as well as stable releases. At least not without more automation or some kind of service handling notifications to us on software releases.
We’re currently at 570 packages in core. That’s a lot of software to keep up with via by-hand audits. We initially discussed always having a “version-named” package and a “generic” that would always point to whatever is the latest stable and I think that might be a good pattern. I’m hesitant to get behind pulling edge versions of software into core.
Going to propose an RFC saying that the “generic” package (i.e. core/docker) should always track stable. We will not track edge cases at this time. Anytime a new stable version of software is released, we create a separate package for the older major version (i.e. when Docker 18 becomes stable, we will create a core/docker17 package).
