Esky patching procedure - esky

I'm trying to auto update using Esky differential patches, but I haven't been able to get the app to update using only those differential patches. It seems like a full version is always needed for a correct update.
So, if I have version 0.1 and patches plus full file versions up to 0.3 in the updates server, the client app will fetch both the patches AND the full latest version file:
updatesServer/
App-0.1.win32.zip (client version running)
App-0.2.win32.zip (this isn't fetched)
App-0.2.win32.from-0.1.patch (this is fetched first)
App-0.3.win32.zip (this is fetched third)
App-0.3.win32.from-0.2.patch (this is fetched second)
Also, if the latest version weren't to be available (App-0.3.win32.zip in this case), the update would fail.
The behavior I would expect is for Esky to get the patch file and update while ignoring the other full file version available so the update is blazing fast. Is there a way to achieve this?
Environment info: the freezer I'm using is cx_freeze and my Python version is 3.4.
Update-routine code:
from esky import *
from esky.util import appexe_from_executable
def restart_this_app():
appexe = appexe_from_executable(sys.executable)
os.execv(appexe,[appexe] + sys.argv[1:])
if hasattr(sys, "frozen"):
app = esky.Esky(sys.executable, UPDATES_URL)
print("You are running version "+app.active_version)
print("Looking for updates...")
if app.find_update() is None:
print("No updates have been found.")
else:
print("Updates available. Updating...")
try:
app.auto_update()
except Exception as e:
print("Error while updating:", e)
else:
print("Update complete.")
print("Restarting app...")
time.sleep(3)
restart_this_app()
BTW, this is my first StackOverflow question ever. Thank you for taking a look at it ;)

This patch is a potential short term fix for the issue.
Please give it a go and let the developers know if it works for you.

Related

Why is it possible to install two MSIs with the same upgrade code?

Building MSIs with WixSharp since years, I always followed this rule which basically says:
For each new release of your application, change the ProductCode but never change the UpgradeCode.
This always worked perfectly but recently I discovered that installing a newer release of my application does not replace the previous version but instead is getting installed in parallel.
Running this PowerShell script gives me this result on a test machine:
My question
What is the reason that a MSI file does not replace an existing one upon installation with the same UpgradeCode?
(I've also posted this as a question on the WixSharp GitHub repository)
Update/solution
I've finally managed to solve it. Basically I did the following things:
Removed the version string from my setups name (since MSI seems to also compare then names to check whether an upgrade is possible; only the same name seems to fit)
Changed my version number from 4 to 3 digits, as Christopher pointed out. I.e. I'm now incrementing e.g. "1.0.0" to "1.0.1" etc.
Added this code to my WixSharp ManagedProject instance:
InstallScope = InstallScope.perMachine,
MajorUpgradeStrategy = new MajorUpgradeStrategy
{
UpgradeVersions = VersionRange.OlderThanThis,
PreventDowngradingVersions = VersionRange.NewerThanThis,
NewerProductInstalledErrorMessage = "Newer version already installed.",
RemoveExistingProductAfter = Step.InstallInitialize
},
After these changes, an upgrade succeeded.
The constraint is ProductCode not UpgradeCode. Only 1 MSI per ProductCode can be installed. Attempting to do so again will be a maintenance operation, small update or minor update.
Many MSI can share an UpgradeCode. (Not a good practice though!) For example it's not required for you to author a Major Upgrade at all.
The usual cause here though is you must change the version number in the first three fields and each install must be in the same context (per-user and per-user or per-machine and per-machine). BTW that's another way to install the same ProductCode twice. One per-user and one per-machine. Again not a good practice.
Good:
1.0.0 → 1.0.1 FindRelated Products in the 1.0.1 MSI will see the 1.0.0 and tell RemoveExistingProducts to remove it.
1.0.0 → 1.0.0 or
1.0.0.0 → 1.0.0.1 Bad. FindRelated will see it as the same version and not remove it.

Terraform Provider-specify version of SDK to pull / Cannot use validation.StringInSlice type schema.SchemaValidateFunc as type SchemaValidateDiagFunc

Due to this problem it looks like for providers you have to get a current version of the SDK (2.4.4 at time of post). This post has a lot of info on how to import a specific version of a package but surely every single provider writer isn't manually pulling the most recent version of the SDK (or are they)?
I'm new to Go/Terraform so maybe I'm missing something obvious but the providers I've found (including the official example) have something like:
import(
"github.com/hashicorp/terraform-plugin-sdk/v2/diag"
"github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema"
"github.com/hashicorp/terraform-plugin-sdk/v2/helper/validation"
)
The current version is not 2 - it is 2.4.4. Now I know those are local paths but what confuses me is when I run something like go get it goes and pulls those down for me. I tried doing:
"github.com/hashicorp/terraform-plugin-sdk/v2.4.4/helper/schema"
but go get very much doesn't like that. How is go get finding those package versions? Is there an import syntax that just gets me the latest build or allows me more granularity? I haven't found a good way to tell what version of the SDK I have after running go get but based on this error message:
it looks like I have 2.0 because that error is, as I understand it, fixed in newer versions of the SDK.
I figured it out. The behavior is controlled by the go.mod file.
In there you'll find:
require (
github.com/hashicorp/terraform-plugin-sdk v1.14.0 // indirect
github.com/hashicorp/terraform-plugin-sdk/v2 v2.0.1
As mentioned by #JimB the v2 is the major version for the plugin. v2.0.1 are GitHub tags. Changing this to v2.4.4 obtains the desired behavior.

When is the right time to update a major version and not minor version in your pom?

I have a utility service x which is in maven repo and is used by some of my other services. We normally update the minor version of the service x when we make small changes and we are currently on version 1.0.15.
No I am making another change and I was thinking whether I should update version to 1.0.16 or I should update the version like 1.1.0.
If anyone can provide an explanation on how this should be done in general, that would I am sure help other developers as well as me. Please let me know if you need further information.
Different projects follow different standards on this, so follow what the repository has done to date.
A well-regarded standard for this is called Semantic Versioning (https://semver.org/). If you are starting a new project or there isn't a standard already in place, I would recommend using this.
Semantic Versions are in the format: MAJOR.MINOR.PATCH.
If you have fixed a bug: increase the patch version
If you have introduced new functionality in a non-breaking way: increase the minor version (and reset patch to 0)
If you have introduced breaking changes: increase the major version (and reset the patch and minor version to 0).
If you are unsure whether your change is a breaking change or not - consider your package (or API) from its consumers' perspectives. If their code has to change as a result of your change then it's a breaking change.

Importing a model into R, that was created in a newer version of H2O

I have H2O version 3.22.0.1 where I have created several models using Flow.
I now want to import them into R (v 3.5.1) for further analysis.
However, the version of the package for R is h2o_3.20.0.8 and I receive this error when running h2o.loadModel()
Error in .h2o.doSafeREST(h2oRestApiVersion = h2oRestApiVersion, urlSuffix = page, :
ERROR MESSAGE:
Found version 3.22.0.1, but running version 3.20.0.8
I saw somewhere in the documentation that the versions must correspond, so is there a (development?) version of the R package for H2O which corresponds to H2O version 3.22.0.1 ? If not, is there any other work-around to import and use models built using Flow 3.22.0.1 in R (other than to revert to version 3.20.0.8 of H2O)
You can download the R package for 3.22.0.1 from here:
http://h2o-release.s3.amazonaws.com/h2o/rel-xia/1/index.html
At the time of this comment, this is the latest stable release.
The version in CRAN is often a release or two behind, but you can always download the latest stable version from the H2O website. All versions of H2O are archived in S3. Every version is there, you just need to find the right link.
The message "Found version 3.22.0.1, but running version 3.20.0.8" means there is a mismatch between the version of the R package and a running H2O server on your host. You might start by making sure the H2O java processes are all stopped before trying to start a new one from R. (If you're not exactly sure how to do that, worst case just reboot your laptop.)
To resolve any problem with H2O version mismatch try
h2o.shutdown()

Installshield does not consider revision number in warning

Lets say my current production version is 1.2.3 and the new product version is 1.2.3.4.
Now, during installation, it will throw a warning message saying something like "The setup has detected the version 1.02.003 of...... already installed. This setup updates ..... to the same version that is already installed, therefore this update is not needed. Do you want to install the update anyway? "
This will be very misleading. Does anybody know a solution for this?
It is not InstallShield, but rather Windows Installer, the underlying technology has the behavior you observe. Take a look at this article, which explains how Windows Installer treats versioning.
The important part for your case is this:
Note that Windows Installer uses only the first three fields of the
product version. If you include a fourth field in your product
version, the installer ignores the fourth field.
This explains why it considers the new one to be the same version. So, the suggestion is either change the third digit, or go with small updates instead. Here is how you can apply small updates by re-installing the product.

Resources