577
edits
Changes
→Check for file version: Check for file version - argument against the use of 'versiongreaterorequal'
:: When checking the uninstall string, it'll perform a downgrade if the version installed on the client is newer than the one distributed by WPKG.
::: Isn't our assumption in this wiki that we're in a 'WPKG world' where application updates are managed by WPKG, so the apps installed on a workstation will always be the same or older than those in WPKG? (and in some environments you potentially also even want newer versions downgraded to the WPKG packaged version so that all apps in the organisation are at the same revision, for better IT support through consistency)- Pete Boyd
:::: Generally yes, but Firefox has its own auto-update mechanism. So a user with admin rights will be prompted to upgrade Firefox by Firefox, possibly before IT gets around to updating Firefox through WPKG. Since Firefox is particularly exposed to security threats it's better for it to be updated to the latest version, even if not done wholly via WPKG.
::::: We turn off Firefox's auto update, because all our user accounts are Limited Windows accounts, so prompting people about an update they don't have the privilige to do anything about can only be an annoyance. I would hope this would be the recommended 'way' that we advise people set systems up at this wiki. In the ill advised situation where people are Administrators (or Power Users?) I agree your point is a good one that at least Firefox remains up-to-date to the latest 3.0.x. However I still maintain that we should have an assumption on this wiki that the admin is doing the right thing and packaging updates as and when they're released and tested. I think by now we've both explained each of our vantages pretty thoroughly :)- Pete Boyd
:: Lets say you want to let the auto update mechanism in place (because your users have sufficient rights to do it ; because you do not have the time to update the wpkg managed software in real time), but want to be sure you upgrade Firefox on every machine, especially on the computers where the users never use FF. You can use the condition "versiongreaterorequal" on the firefox.exe file to achieve this. For Firefox 3.0.6 it will be : <check type="file" condition="versiongreaterorequal" path="%PROGRAMFILES%\Mozilla Firefox\firefox.exe" value="1.9.0.3306"/>
=== Check for file version (in the rapid release era) ===
Continuing with this thread, but at this later date, where we now have major Firefox versions at a minimum of every 6 weeks, and before we have [https://wiki.mozilla.org/Enterprise/Firefox/ExtendedSupport:Proposal Extended Support Release (ESR)] versions... If you have your suite of Firefox or Thunderbird add-ons matched to your version of Firefox, and those add-ons are crucial to your users' work, then allowing Firefox to upgrade independently of your managed suite of apps could upgrade it to the next major version for which those add-ons potentially aren't yet available. For me this is an argument against the use of 'versiongreaterorequal' for Firefox (and Thunderbird) [[User:Pete|Pete Boyd]] 11:32, 17 November 2011 (CET)
== Package version confusion and other nonsense ==