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.
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.
I am working on the installer for a product (currently version 3). Between versions 1 and 2 (already released), the guid of a component was changed, but the keypath adn everything stayed the same (and needs to stay the same still). In version 3, I need to make a change to move RemoveExisitingProducts later in the install sequence. However, this is exposing a new bug causing the component that had its guid changed to not be installed if upgrading from version 1 to version 3. I'm trying to figure out a way around this bug. Repairing fixes the installation but I'd rather not have to repair. I think it'll probably take some kind of hack to fix it, but I haven't been successful. I tried going to HKLM/Microsoft/windows/currentversion/installer/user data/S-15-18/components/OLDPACKEDGUID and deleting it before running the new installer, but that seems to cause terrible issues and be much worse.
anyone know a solution to this issue, even if it's a big hack?
Thanks
You can try to schedule RemoveExistingProducts earlier in the sequence so that during upgrade the previous product is completely uninstalled before installing the new product.
Also look at this WiX upgrade question. And another one may also be helpful.
We have a software that has couple of executables inside. One of the executables is Windows service, and it doesn't change that often, usually we release many updates to the main executable, but the service version is same inside installer.
When service is installed first time or upgraded with newer version, we need to run custom action. We managed to solve first install part, but we don't know how to determine that version we're installing now is newer than one that already exists. Sort of if(newver > oldver) run custom action.
Thank you in advance
- Jack
You can try using the upgrade rules of your package. More details here: How to implement WiX installer upgrade?
Rob Mensching (the second answer in the linked thread) shows an example for upgrade rules. You should first familiarize yourself with the Upgrade table and how upgrade rules work. There isn't an easy answer or a quick fix for this in WiX.
Basically, you should have 2 upgrade rules
the first sets a property when an older version is found
the second sets another property when a newer version is found
After that you can use the older versions property to condition your custom action. For example, if the property is named OLDERVERSIONFOUND the custom action condition can be:
OLDERVERSIONFOUND
or something like
OLDERVERSIONFOUND > "1.0.0"
Your best bet is to store the "service" version somewhere in the registry, search for that registry value during upgrade and run your CA if newver > oldver (and the CA should also update said registry value to newver)
Note that Custom Actions are (generally) an admission of failure. I always try to separate out the configuration portion of setup to a pre-install (for sysadmins doing deployment) or post-install (for interactive installations) step - often a separate executable.
Declarative installations with no custom actions are much more reliable - if you can figure out how to rewrite the service so that your custom action is no longer required, you'll be much better off in the long term (this doesn't help when you're under pressure to release now, but it's something to think of for future releases)
At work I'm using Perl 5.8.0 on Windows.
When I first put Perl on, I went to CPAN, downloaded all the sources, made a few changes (in the .MAK file(?) to support threads, or things like that), and did nmake / nmake test / nmake install. Then, bit by bit, I've downloaded individual modules from CPAN and done the nmake dance.
So, I'd like to upgrade to a more recent version, but the new one must not break any existing scripts. Notably, a bunch of "use" modules that I've installed must be installed in the new version.
What's the most reliable (and easiest) way to update my current version, ensuring that everything I've done with the nmake dance will still be there after updating?
As others noted, start by installing the new perl in a separate place. I have several perls installed, each completely separate from all of the others.
To do that, you'll have to configure and compile the sources yourself. When you run configure, you'll get a chance to specify the installer. I gave detailed instructions for this in an "Compiling My Own Perl" in the Spring 2008 issue of The Perl Review. There's also an Item in Effective Perl Programming that shows you how to do it.
Now, go back to your original distribution and run cpan -a to create an autobundle file. This is a Pod document that lists all of the extra stuff you've installed, and CPAN.pm understands how to use that to reinstall everything.
To install things in the new perl, use that perl's path to start CPAN.pm and install the autobundle file you created. CPAN.pm will get the right installation paths from that perl's configuration.
Watch the output to make sure things go well. This process won't install the same versions of the modules, but the latest versions.
As for Strawberry Perl, there's a "portable" version you can install somewhere besides the default location. That way you could have the new perl on removable media. You can test it anywhere you like without disturbing the local installation. I don't think that's quite ready for general use though. The Berrybrew tool might help you manage that.
Good luck, :)
I would seriously consider looking at using Strawberry Perl.
You can install a second version of Perl in a different location. You'll have to re-install any non-core modules into the new version. In general, different versions of Perl are not binary compatible, which could be an issue if you have any program-specific libraries that utilize XS components. Pure Perl modules shouldn't be affected.
If you stay within the 5.8 track, all installed modules that contain XS (binary) extensions will continue to work, as binary compatibility is guaranteed within the same 5.8 series. If you moved to 5.10 then you would have to recompile any modules that contain XS components.
All you need to do is ensure that the new build lists the previous include directories in its #INC array (which is used to look for modules).
By the sounds of it, I think you're on Windows, in which case the current #INC paths can be viewed with
perl -le "print for #INC"
Make sure you target your new Perl version in another directory. It will happily coexist
with the previous version, and this will allow you to choose which Perl installation gets used; it's just a question of getting your PATH order sorted out. As soon as a Perl interpreter is started up, it knows where to look for the rest of its modules.
Strawberry Perl is probably the nicest distribution on Windows these days for rolling your own.
I think the answer to this involves virtualisation of some kind:
Set up an exact copy of your current live machine. Upgrade Perl, using the same directory locations and structures as you're using at the moment.
Go through your scripts testing them on the new image.
Once you're happy, flip the switch.
The thinking behind this is that there's probably all sorts of subtle dependencies and assumptions you haven't thought of. While unlikely, the latest version of a particular module (possibly even a core module, although that's even more unlikely) might have a subtle difference compared to the one you were using. Unless you've exhaustively gone through your entire codebase, there's quite possibly a particular module that's required only under certain circumstances.
You can try and spot this by building a list of all your scripts - a list that you should have anyway, by dint of all your code being under version control (you are using version control, e.g. Subversion, yes?) - and iterating through it, running perl -c on each script. e.g. this script. That sort of automated test is invaluable: you can set it running, go away for a coffee or whatever, and come back to check whether everything worked. The first few times you'll probably find an obscure module that you'd forgotten about, which is fine: the whole point of automating this is so that you don't have to do the drudge-work of checking every single script.
When I did it I installed the newer one into a separate directory. There's a bit of added confusion running two versions, but it definitely helps make sure everything's working first, and provides a quick way of switching back to the old one in a pinch. I also set up Apache to run two separate services, so I could monkey around with the newer Perl in one service without touching the production one on the old Perl.
It's probably a lot wiser, in hindsight, to install on a separate computer, and do your testing there. Record every configuration change you need to make.
I am not sure about building it yourself—I always just used prepackaged binaries for Windows.
I'm not sure I understand exactly what you're asking. Do you have a list of changes you made to the 5.8 makefile? Or is the question how to obtain such a list? Are you also asking how to find out which packages above the base install you've obtained from CPAN? Are you also asking how to test that your custom changes won't break those packages if you get them from CPAN again?
Why don't you use ActivePerl and its "ppm" tool to (re)install modules?