Best practices for install project versions/patches
Brought to you by:
damonc
Menu
▾
▴
#6 Best practices for install project versions/patches
This is a great product (using 1.1b2) and I am working on readying the release of some software, but I am struggling with how to setup my install projects, and it's probably due to my inexperience with software installers.
I am working on creating an installer for an application, let's call it release 1.1.0.0. The code for the application is managed in cvs, so I read inside the help files that I should include my .mpi file inside cvs which makes sense.
However, where I am struggling is with what I do with each of the .mpi files. So, I have the installer specify the file groups based on what is in cvs and it creates my installer, tagging all the files as 1.1.0.0.
So, let's go with a patch first. I have to patch a jar file within my application, call it version 1.1.0.1. Do I need to duplicate the entire .mpi file, take the application id and put it in the upgrade application id setting, remove all of the existing files and groups I defined and cut things out like the license agreement page? I have a somewhat complicated install that needs to run some external programs for it to work correctly. I assume this .mpi would sit in the cvs patch branch location. I install the patch, and the jar file now has 1.1.0.1 in the .installinfo file.
If I create another patch for this version, 1.1.0.2, then that jar would have 1.1.0.2 attached to it.
Now, if I have release 1.2.0.0 ready to go, I assume I duplicate the 1.1.0.0 .mpi file and adjust it to have the new files that have been added. What do I do about the files that have been removed, or relocated, do I need to create my own delete file, rename file tasks within the installer group? Also, I assume this means I should just go with the update if dates are newer approach for the files, but the version number might make more sense. However, the next question is, can a customer install 1.2.0.0 over 1.1.0.(0,1,2), and do I just change the versions of the files that truly are newer to 1.2.0.0 and leave the others as 1.1.0.0? I would have to track this inside of cvs I guess.
What happens if the .installinfo contains files that are no longer included in 1.2.0.0 and the customer already has 1.1.0.0 installed? Do I need my future installers to edit this file, or are these extra entries in the file harmless?
Sorry if this is a basic question, but I would like to know the best way to go about this, so I don't spend a lot of effort on this.
Thanks,
-Bill
Logged In: YES
user_id=50387
Originator: NO
Let me see if I can sum up some of the way it all works, and hopefully that will answer all of your questions. If not, I'll try and be more specific.
Ok, so let's assume your scenario of releasing version 1.1.0.0, then 1.1.0.1, then 1.1.0.2, and finally 1.2.0.0. I'm going to assume that the 1.1.0.x releases are patches to the 1.1 release, while the 1.2 release is a full new version.
For the patch installers, you would want to create a new project and use the Upgrade Install ID property to specify the application ID of the original application that you are updating. This will allow InstallJammer to tie the pieces together during uninstallation.
When one installer matches the Application ID or Upgrade Application ID of something already installed on the target system, all of the information for that install is grouped with the other installs. This allows you to have a single uninstall that includes all the patches and versions the user has installed up to now.
File versions are set when the file is installed, so if a file in the patch installer does not match and install, the file that is already there will maintain its current version. So, if you install 1.1.0.1 over the top of 1.1.0.0, only the files that get updated will reflect the new 1.1.0.1 version. Any file that was not updated still has the 1.1.0.0 version.
So, if you then install 1.1.0.2, you could potentially have files in the directory that have one of three versions: 1.1.0.0, 1.1.0.1, 1.1.0.2 depending on which files are installed with each patch.
For the 1.2 release, I would probably make a whole new project and change the Application ID to the same ID as the original application. A 1.2 release would probably not be a patch installer since you would most likely want to distribute the entire program with a new minor version.
Since it has the same Application ID as all the other installers, the information from the install will all end up in the same registry. What this means is that a single uninstall will uninstall all the previous versions.
Any file in 1.2 that overwrites an old file will update that file's version number, but the other files will remain at their older version. It all depends on how you set it up.
Just a few things to remember (and I will probably write all this up into a section of the documentation):
* The Application ID and Upgrade Application ID of a project only mean that the information is all stored in the same location.
* An uninstaller attempts to uninstall by Application ID, so it will look up all the files that were installed with that ID.
* File versions do not update unless the file is actually installed. If the file is skipped for any reason, the old version stands.
Just remember that every file in your installer can have a different version, so you can completely control the versioning. They just take <%InstallVersion%> by default.
I hope that information helps you. If you have some more specific questions now that you understand all that, I'm more than happy to help. 0-]
Logged In: YES
user_id=1645784
Originator: YES
Wow, Damon, thanks for the great response.
Everything you said makes sense.
What do I need to do about files that might not be present in version 1.2 that were around in 1.1.x.x? Do I need to manually update the .installinfo file, or if files are contained in that list that don't exist anymore, they will be removed?
My application is a packaged J2EE web application that needs to be expanded and files dropped into the correct locations, and then some build assembly scripts need to be run afterwards.
For subsequent installs (application runs on windows, solaris and linux) is there a platform independent way I can find the previous install? I assume I need to write something into the registry on windows. What about on unix? This most likely won't be assembled as a package, so is there some sort of registry for the applications, or should I assume it is always installed into /usr/local (think this is a bad approach).
Thanks for the great support and great product!
Logged In: YES
user_id=50387
Originator: NO
If 1.1 leaves behind some files that 1.2 doesn't use anymore, that's ok. They will still be in the install info when the uninstaller goes to run. They will, however, still be there. So, if you have some good reason for getting rid of a file that is no longer part of your software, you either want to make the user properly uninstall the previous version, or you want to delete the file behind with a Delete File action.
If it's ok that the extra file is still out there, you don't have to worry about it. The uninstall will still take care of it. No file is ever removed from the install info once it's in there. If the uninstall encounters a file in the log that is no longer on the system, it just quietly skips over it.
As for previous installs, InstallJammer keeps its own registry of install information on the system. The location of the registry is not important (though it's in the docs), what it does is track every install on the system by its Application ID.
You'll want to read up on the Check for Previous Install action. That will get you the information for the most recent install. If you need to dig into other previous installs, you'll need the Get Previous Install Info action, but it'll take a little trickery to get it all working.
If you read through the Check for Previous Install documentation, you'll see all of the information that is available in the log for each installation. If you want to log some of your own data in that registry so that you can pick it up later on subsequent installs, you can look at the Add Install Info action. It lets you add your own information on top of what InstallJammer already records.
Hope that helps you out! 0-]
Logged In: YES
user_id=1645784
Originator: YES
Well I re-read your statement about checking for previous install documentation and can't seem to find it in the help menus. I tried doing a search and everything I tried returned 0 pages. "Condition", "action" etc. returned nothing. So, where is this documentation so I can take a look at it?
Logged In: YES
user_id=50387
Originator: NO
The help documentation is under the Help menu from the top. The help docs are installed with every copy of InstallJammer, so yours should be there. If not, you can look at the online docs at:
http://www.installjammer.com/docs/
It looks like the search for the HTML docs is not picking up everything it should. I'll look into that for the next release. What you are looking for is in InstallJammer Help -> Actions -> Install Actions. Take a look at:
Add Install Info
Check for Previous Install
Get Previous Install Info
Let me know if you can't find it or need more help on it.