The root cause is that when we made anarki open to incompatible changes we didn't think it would be automatically pulled into VMs like openshift or docker. You can only use a shifting substrate like anarki if you can control when to take in updates.
I'm not sure what to do about this. What do you think?
It's true that the constantly shifting nature of anarki has caused all of us more than a few issues in the past. There's even been more than one breaking change since I started supporting OpenShift. But I think that keeping anarki open to change is a good thing, and I don't want to get it locked down. You end up with issues like the python2.7 vs 3 fiasco.
On the other hand, it's probably a good idea to regularly catalog the changes, and employ some sort of semantic version tagging. Then it could be up to other users when they should upgrade, and they can be better informed of why.
Absolutely, I'd be the last person to suggest the backwards-incompatible changes (most of them mine :) stop. No, I meant, is there some way we can configure things like openshift to pick up at specific tags? Maybe you could hardcode to checkout to a specific hash? I don't know what the consequences would be, though. For example, if people want to hack on the code inside openshift. Thoughts?
Another approach may be for you to maintain a fork of anarki and clone from it instead of anarki directly. That way we wouldn't be dealing with detached heads inside openshift, and it'll still require a manual step to upgrade.
It shouldn't be that hard to clone the latest anarki, and then checkout a specific tag. I just didn't bother because we haven't been using tags much that I know of.
Of course, my script only installs anarki once; it doesn't upgrade it out from under the user. The only issues are if something changes that affects the actual openshift base, like when you changed the boot script a few months ago.