dokku_packages_state doesn't support version pinning

[strugee]

Description of problem

dokku_version and friends are marked deprecated in favor of dokku_packages_state, but the latter doesn't support pinning the Dokku version. I'm uncomfortable simply specifying latest in a world where Dokku still routinely ships breaking changes.

Seems like this should take either the current values or a version number? I might also be misunderstanding the impetus for this deprecation - I'm guessing it's to avoid specifying conflicting *_version numbers, but I could be wrong.

Omitting the rest of the issue template since it obviously isn't relevant.

[ltalirz]

hey @strugee , the reasoning is explained in #137 but I've held off merging this PR since I also had my doubts (see also #137 (comment)).

Do I take it correctly, that you would agree with #137 (comment) ?

Let me know what you would prefer

[AndrewKvalheim]

#137 discusses the unpinning of Dokku’s dependencies, which makes sense as the dependencies are already managed by the package and need not be doubly specified.

What comes as a surprise is its unpinning Dokku itself at the top level. Dokku’s documentation instructs us to read the migration guides prior to upgrading, making manual control over Dokku’s version a requirement.

[josegonzalez]

I wonder if we should make it present instead of latest as default.

On the dokku side, what can I do to help decrease the pain around upgrades? Once we hit a 1.0 (I hope this year) I don't expect any more breaking changes (just lots of warnings until the next major), but what can I do keep in mind as part of my release process?

[josegonzalez]

I also want to say that all the dokku dependencies usually (but not always) have much stronger backwards compatibility guarantees as I don't control whether someone upgrades just dokku vs everything.

[AndrewKvalheim]

On the dokku side, what can I do to help decrease the pain around upgrades?

Thanks, but I don’t have any pains in mind; where I’m coming from is just trying to follow the instructions and set up our host correctly. Dokku may make breaking changes, therefore upgrades require human review.

[ltalirz]

#137 discusses the unpinning of Dokku’s dependencies, which makes sense as the dependencies are already managed by the package and need not be doubly specified.

If you look at the code, the PR would actually also remove the dokku_version configuration option, leaving only the dokku_packages_state option.

I wonder if we should make it present instead of latest as default.

@josegonzalez This is already the case, see https://github.com/dokku/ansible-dokku#dokku_packages_state
If you do not specify dokku_version explicitly, it will install the latest version at the first run, and then keep any present version.

If I understand correctly, then we would all agree with the following solution:

• we keep dokku_version; by default it will still be empty, but users can specify it in order to force installation of a specific dokku version
• we drop herokuish_version,plugn_version, and sshcommand_version, as these versions should be determined by the dokku package
• we keep dokku_packages_state; by default it will remain present (it would better be named dokku_package_state now, but let's not change a name just for this)

Does that sound reasonable?

[strugee]

#162 (comment) makes a lot of sense to me!

@josegonzalez I'll also echo what @AndrewKvalheim said (though caveat, we do work together on SeaGL) - there aren't any pain points per se, and quite frankly we actually had been accidentally upgrading Dokku every Ansible run without even knowing it for a while and never hit any problems which is a testament to how sensible things have been. But it makes me nervous to have this stuff somewhat auto-updating when we have, for example, an active conference Call for Proposals relying on it being up and stable. That'll be the case post-1.0 too; while obviously the additional compat guarantees are nice, I'd still like to be firmly in the driver's seat when we upgrade so we can do a quick smoketest just in case and rollback if things go awry.

(As an aside, thanks to you all your hard work on Dokku, its Ansible playbook, etc. - it's been such a pleasure to use for us and has allowed us to accomplish much more, much faster than we otherwise would've been able to. That speed was a massive help right around crunch time last year!)