Letsencrypt.exe may also need to rename? In win-acme.v1.9.9.0.zip until that old name of file.
Maybe, but we'd to be really clever about it because there are a lot of scheduled tasks out there configured to run letsencrypt.exe. That's why I've pushed this into the future, perhaps even to a v2.0.
The alternative is to distribute two executables for some time. We'd then have the one called letsencrypt.exe change the scheduled task that calls it :).
Maybe I don't understand something, but if the task already exists in the scheduler, it contains the path to the executable file of the previous version. And running a new version and getting certificates with it does not change anything, unless you force a task to be re-created. Therefore, I think it is quite possible to create new tasks with a new name executable file.
Can you run the new version to ask the user to Update the task? (y/n): And update already with a new name exe.
And the application folder name also remained the same. Offer the clean install and rename it :)
For the past half year I've made sure that you can copy a new version of the program to your server with confidence that your existing workflows (tasks, scripts and previously scheduled renewals) keep working as-is.
That way you can get bug fixes without finding yourself in reconfiguration hell. Not such a problem for a single server perhaps, but if you operate dozens of servers with hundreds or thousands of sites and have custom automation built around it, that gets annoying really fast.
This is the promise of semantic versioning. There have been a few notable exceptions, but all for good reasons.
I agree with your sentiment that it'd be nice to offer a clean install with the new name, but dealing with legacy is an important part of the software development game. In my opinion the most successful products adhere to this philosophy.
There might be a 2.0 version someday that break things in a major way, but it'd have to offer some compelling reasons why it's worth the hassle. Esthetics is usually not one of them.
So I'll keep thinking about 'clean' ways to handle the rename.
Most helpful comment
For the past half year I've made sure that you can copy a new version of the program to your server with confidence that your existing workflows (tasks, scripts and previously scheduled renewals) keep working as-is.
That way you can get bug fixes without finding yourself in reconfiguration hell. Not such a problem for a single server perhaps, but if you operate dozens of servers with hundreds or thousands of sites and have custom automation built around it, that gets annoying really fast.
This is the promise of semantic versioning. There have been a few notable exceptions, but all for good reasons.
I agree with your sentiment that it'd be nice to offer a clean install with the new name, but dealing with legacy is an important part of the software development game. In my opinion the most successful products adhere to this philosophy.
There might be a 2.0 version someday that break things in a major way, but it'd have to offer some compelling reasons why it's worth the hassle. Esthetics is usually not one of them.
So I'll keep thinking about 'clean' ways to handle the rename.