- NSIS Discussion
- Upgrade from v2.28 to v2.37?
Archive: Upgrade from v2.28 to v2.37?
vc6
29th June 2008 03:13 UTC
Upgrade from v2.28 to v2.37?
I have been using NSIS version 2.28 until now. I just discovered that version 2.37 is available now. I read the release notes for 2.37, but it only lists the differences between 2.36 and 2.37.
Where can I find a list (or lists) of the differences between version 2.28 and 2.37?
Thanks!
vc6
29th June 2008 04:24 UTC
Originally posted by LoRd_MuldeR
You can see the changelogs on SourceForge:
http://sourceforge.net/project/shown...group_id=22049
http://sourceforge.net/project/shown...group_id=22049
http://sourceforge.net/project/shown...group_id=22049
http://sourceforge.net/project/shown...group_id=22049
And so on...
Thank you! This is exactly what I was looking for. I was looking for it in SourceFourge.net but found only the complete packages to download. I only needed the release notes but couldn't find them. Now, thanks to your reply, I discovered that the trick is to click the note ICON.
vc6
29th June 2008 13:34 UTC
I forgot to ask: is v2.37 backward compatible with v2.28? That is, if I have an NSIS script working perefectly in v2.28, is it guaranteed to work identically in v2.37?
Thanks.
LoRd_MuldeR
29th June 2008 13:48 UTC
Originally posted by vc6
I forgot to ask: is v2.37 backward compatible with v2.28? That is, if I have an NSIS script working perefectly in v2.28, is it guaranteed to work identically in v2.37?
Thanks.
The most convenient way to check this is: Install NSIS v2.37 and try to compile your script. If it fails to compile and you are not willing to fix it, you can go back to NSIS v2.28 at any time. Nevertheless I personally wouldn't release software based on an "outdated" NSIS version, because your installer will contain bugs that have already been fixed...
dandaman32
30th June 2008 06:09 UTC
NSIS compatibility has been nearly perfect since 2.0. Stuff like SubSection was renamed to SectionGroup but still compiles (albeit with a warning) if you use SubSection. Even the notorious hacks I used in the ExperienceUI and Component Manager still seem to work in the latest releases, and if my crappy code stayed compatible, then I guarantee yours won't have a problem. :D
Kudos of course to the devs for all that compatibility work :)
--Dan
vc6
30th June 2008 15:55 UTC
Originally posted by LoRd_MuldeR
The most convenient way to check this is: Install NSIS v2.37 and try to compile your script.
Thank you both, LoRd_MuldeR and dandaman32. That is exactly what I just did. It seems to have gone OK.
One observation, though:
When installing v2.37, I chose the "uninstall existing version" first (I like to work "clean", without the confusion of having two different versions of the same program installed side by side). It deleted the Plugins and Include subdirectories (that's good),
including the ones that I placed there manually (that's surprising).
I fixed that pretty quickly, but it would be nice if things that were added manually (i.e. not by the installation program) to the C:\Program Files\NSIS directory tree, had not been deleted automatically.
Sheik
30th June 2008 16:05 UTC
Yeah, it deleting ALL my plugins, even ones it didn't place in there, is really bad.
I suspect it all comes back to the fact that NSIS doesn't keep track/know about "its files" during Uninstall.
Its ironic in a way, there are HUGE warnings about not doing an RMDIR /r, and then the Uninstaller for NSIS goes and does it!
> RMDir /r $INSTDIR\Plugins
In fact, it also "whacks" all of include and contrib too:
> RMDir /r $INSTDIR\Contrib
> RMDir /r $INSTDIR\Include
Which is REALLY bad, as we might actually have 3rd party NSIS stuff, that installs into Plugin/Contrib/Include, and oops, they are all gone!
Personally, I still feel this is one of the biggest deficiencies of all of NSIS...
ie, the lack of any install logging by DEFAULT in NSIS, for later use during Uninstall.
I know there are plugins/hacks/etc that allow us to be smarter about uninstalling, but why should they be plugins/extras?
To me, this problem is so fundamental/critical, that the installer/uninstaller should have the install logging builtin from Day 1.
Anders
30th June 2008 16:43 UTC
the official word is (IIRC), nsis\plugins is for nsis only, use !addpluginsdir for 3rd party stuff, also you could just install over the top of the old install without uninstalling first. I do agree that nsis needs better per file logging support
Sheik
30th June 2008 17:08 UTC
Hi Anders,
I believe most of the 3rd party plugins/scripts that are linked on NSIS web page, don't follow that rule...
As far as I can tell, nearly ALL of them install into the raw NSIS directory structure.
As for the file logging support...
I am still not sure why there is such a reluctance against doing it. I can't name one other Installer/Uninstaller combo that doesn't have some sort of install log that is used for uninstalling purposes.
kichik
11th July 2008 11:16 UTC
Originally posted by Anders
the official word is (IIRC), nsis\plugins is for nsis only, use !addpluginsdir for 3rd party stuff, also you could just install over the top of the old install without uninstalling first. I do agree that nsis needs better per file logging support
True.