Detect if configlet is at the latest version

[kytrinyx]

The discussion in https://github.com/exercism/docs/pull/110 raised some issues regarding improvements to Configlet in the context of UUIDs that get submitted, but which are incorrect.

Since older versions of Configlet were using a UUID library that generated invalid UUIDs, one thing we can do to help improve the situation is ensure that Configlet is up to date.

The approaches I can think of are:

• have a separate command (maybe it would be enough to implement an upgrade command per https://github.com/exercism/configlet/issues/112)
• have a check that runs on every command (not a fan since mostly configlet doesn't go across the wire, and this would add a lot of overhead)
• have a config file that logs the last time it checked for an update, and check only if a certain amount of time has passed

[rpottsoh]

I am for either form of the 1st option.

[coriolinus]

As I see it, you need all those behaviors: every time a command is run, you want to check internal state, which may be a config file, and determines when the last version check was made. If it exceeds some threshold, it goes over the wire for a small request to get the current version. (This should behave well if the network is unavailable or laggy, meaning it runs concurrently with the actual command being executed and fail silently if at all.) Finally, if a newer version is available, it should prompt the user to run the upgrade command to actually modify the installation.

[nywilken]

I’m a fan of all three options, with some slight modifications. For the upgrade process #112, I think we could leverage the cli pkg in exercism/cli which is responsible for checking if a binary is out of date and upgrading to the latest version.

At a minimum users of configlet should be encouraged to use the same version used on Travis. Would anyone be opposed to showing the version with the build date as metadata at command run (e.g 1.0.0+20130313)? So that users can see how old the build is and compare it to Travis runs if they wish or check for an update.

When it comes to going over the wire, we could add a flag to disable that check for those users who update regularly. Thoughts?

The config file is a nice idea, but where would we store the file? Should configlet have a config directory to store this type of info?

[tleen]

It will need some sort of auto-check for current version. If a user is unaware that configlet is updated they may not think to run the update command. I'm often surprised at how many track maintainers don't even use it, let alone monitor its release status.

Over the wire every invocation is not great, and we would probably want to disable it entirely for travis linting?

A config file for one thing may be overkill, perhaps we can just store the last checked time in a tmp dir file or something?

[nywilken]

It will need some sort of auto-check for current version.

That's the idea. The current version is easily accessible within configlet so it would be just printing in a way that it is not disruptive to the normal output.

If a user is unaware that configlet is updated they may not think to run the update command.

I hoping that if a user sees that the build date in the version string is, lets say, older than x months or even a year old they would be inclined to check for a new release. Is that a stretch?

A config file for one thing may be overkill, perhaps we can just store the last checked time in a tmp dir file or something?

So in thinking about this a little more, if we added the date of the last build as build metadata to the version we would be able to use that information to determine if configlet should check for a new available release. Removing the need for a tmp dir/file entirely.

Over the wire every invocation is not great, and we would probably want to disable it entirely for travis linting?

Travis always pulls down the latest version of configlet so there wouldn't be a need to run the check.

[tleen]

All good ideas here. Esp. the metadata one. Would strive to avoid files if it can be avoided.

I really don't think users will think to check for a new release. Just not part of their workflow.