Arc Forumnew | comments | leaders | submitlogin
2 points by shader 1601 days ago | link | parent

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.

1 point by akkartik 1601 days ago | link

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.


1 point by shader 1601 days ago | link

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.