How to manage InstallScript differential upgrades and releases.
For every version I ship, do I need to keep two releases? One for existing customers - for upgrade and one for new customers for fresh install?
Then as the product continues its life cycle, Do I need to keep all those releases so that I could create a differential upgrade?
Is that the way companies handle their releases? seems like a lot of data to keep and handle...
Are the savings (time or size) of differential upgrades worth this hassle? It sounds like it would be significantly easier to just release full the installer for both scenarios.
Whether or not you use them to create differential releases, I would suggest keeping all your previous releases around. You never know when you'll need to test the behavior of an old release, and the only real way to do that is with its original bits.
Installshield basically just moves over all of the files to the target machine's folder. Lets say you are going from version 1.0 to 3.0. Is there any real point in your case to upgrade to 2.0 before going to 3.0? Or could you really just lay down 3.0 directly? Unless you NEED an updater, then there's no point in having one.
How we handle it, is that we have two build like you said. A 'Fresh install' and 'Updater.' We need the updater though, because we have linear database migrations that need to run for each hotfix before the software can reach the newest version, so we can't just "skip" that 2.0
If we need to apply a hotfix, we create a stripped down version of the updater until the next release, where I create another Fresh install and Updater.
Related
I have a big database of activities which in the LCI have activities from an old ecoinvent version.
Is there a fast and easy way to update all the LCIs in the database so that they use a newer version of ecoinvent?
I suppose there might be problems of activities not existing anymore/changed names, if that can be a case, how do you manage that?
I'm new to Brightway so I have no idea about how to do this ;).
Thanks a lot!
Daina
There isn't yet, but we are working on it. What we normally recommend is to have a reproducible workflow, using whatever data source you prefer. It is very helpful to be able to reproduce your projects if something happens to your computer, and in this case you could re-create your own data and link it to a newer version of whatever database. But you are right, things change from version to version, and this normally requires some metadata on how to handle these changes - hence the library under development.
On the website of Debian, it's written about point releases:
They usually incorporate the security fixes released until the time of
the update and fixes for grave bugs in the current release.
If I correctly understand, that means only minor updates can occur in the packages of the current stable version, right?
In other words, I want to know if a binary who depends of a library in a specific version (libmicrohttpd.so.12 for instance) will stay compatible in the next point releases of Debian.
Yes, but it is very seldom.
In general you are right, the point releases should not change existing API and ABI.
But there could be problems on doing that: security changes would require a lot of work, and upstream will do only for the new version. In such cases the version will be dump. But this is very seldom: it would need a security bug which effect the fundamental design of a library (not just some coding error).
In any case the old version will remain on archives, and you can keep it (so that it would not be automatically removed), so that you can still use, hopefully with relevant safe guard.
We build our installs\releases using Install Shield. I have come to a situation where we have a patch that cannot be upgraded by a release with a higher version number, that is missing components included in the patch.
After releasing a full minor release (i.e. 7.2.0) we released a patch on a previous full minor release (i.e. 7.1.12).
The Patch 7.1.12 had files and components added that do not exist in 7.2.0. The patch is not uninstallable.
It is now impossible to upgrade 7.1.12 to 7.2.0 because of the missing components. Some customers specifically want to upgrade to 7.2.0 and not a later version (7.3.0) where the components can be added to fix the issue.
Short of uninstalling 7.1.12 and then installing 7.2.0 I couldn’t find any solution to fix.
Is there any way around this? Can we build a 7.1.13 as a bridge to somehow fix the mistake. Or use an argument when installing 7.2.0 to get around this.
I looked around the registry and I am trying to figure out if it is possible to remove the components through the registry.
I tried deleting the component entries in the registry. that didn't do it.
If I delete the product entry in the registry that works - but it must be overkill.
I also tried deleting the patch msi from C:\Windows\Installer but that didn't do it.
There must still be a way to unlink the component from the feature in the registry without deleting the entire product.
It sounds like you're trying to do a series of Minor Upgrades, with at least 7.1.12 delivered as a patch. Using minor upgrades imposes various limitations; anything that requires you to Change the Product Code must be avoided. In your case, note that adding components is allowed, but not the reverse:
The update can add a new component to a new or an existing feature.
The product code must be changed if any of the following are true for the update:
A component is removed from an existing feature.
In short, any modifications to the feature-component tree, other than the addition of new ones, is going to require changing the product code, and thus a Major Upgrade. Major upgrades perform an uninstallation behind the scenes, and thus are less restrictive about the changes they are allowed to deliver.
You have two options:
Use a major upgrade, or some other means of uninstalling the old installation before installing the new version. If possible, this is what I would recommend. Using minor upgrades often adds more difficulty than benefit (though your needs may differ).
Maintain the new components in your newer versions. Note that you do not necessarily have to maintain the resources within them:
The update can add, remove, or modify the files, registry keys, or shortcuts of components that are not shared by two or more features.
But you will have to make additional changes to account for the changes to the resources. In your case, this probably will require additions to the RemoveFile table, and may be best served by "puncture component" pattern.
Spelunking through the registry for a workaround that modifies Windows Installer's bookkeeping is a bad idea. It may work, it may appear to work, or it may not work at all. In no case is it supported.
If both versions 7.1.12 and 7.2.0 are already publicly released, you're in a rough spot. I think your best bet there is to re-release 7.2.0 with a new product code and version, e.g. a 7.2.1 major upgrade. You can advise your end users that those already at 7.2.0 don't need to install it.
Can you suggest a tool(if exists) to keep track of all the versions of all the resources i use to develop a project?
i.e. Project:Myproject
IDE:Eclipse
php:5.0.2
iReport Plugin:1.2.1
...
Thanks.
One approach is to use source control: check in the binaries (or installers) for all the tools you use along with your project. When you upgrade a tool, check in the upgraded version, so the source control history includes everything that is needed to build a particular version of your project. If you want to build last year's version of the code, everything you need is then in source control.
(Disk space is cheap, so just keep a copy of everything)
I am doing a concept in linux in which i want to do version rollback for an app installed in linux. Is it possible??
For eg I have an application named X with version 1.1
I get an update. It changes it to version 1.2
I note what all the packages in the app going to be modified.
Then i save them and apply the changes.
Now after sometime due to some problems I want to switch back to version 1.1
If i undo the changes and make the entire solution will the rollback be done?
The easiest and common way in Unix is to install them in separate directories,
eg "/usr/bin/MyApp.1.2.3" and "/usr/bin/MyApp.1.2.4" then create a link to the one to use "/usr/bin/Myapp".
Changing versions is then just a matter of moving the link.
You don't need to invent anything. Just keep the packages you install around. If you want to go back, uninstall the current version and install the previous package again.