GNOME Bugzilla – Bug 596864
deprecater / version freshness checker
Last modified: 2012-04-27 19:50:48 UTC
We should have an opt-out "latest supported version" check, that would warn users about outdated, unsupported versions (the infamous 0.11.x series, for a current example). Something that checks for the latest stable version number in the "VERSION" file on website compared to a "MINIMUM_VERSION" file, and so we can use that to "phase out" old versions by incrementing the version number in MINIMUM_VERSION on the website. The user would then get a non-intrusive dialog/notification (I'm thinking of a libnotify toast) saying that his/her version is "so last year" and that we are not supporting it, or something along those lines. I will attempt making a patch for this myself (no guarantees though). It is of course too late for old versions such as 0.11.x since they are already released, but this feature would be nice and helpful for future versions. Especially in preventing bad impressions on users based on outdated versions.
Agreed.
Created attachment 150889 [details] [review] patches implementing version checking, needs guidance. looking for some feedback, these patches implement the basic parts of version checking. location of xml file is currently set to '/home/stephen/text/version.xml' and would have to be changed if tested. *I will attach the xml file used underneath.
Created attachment 150890 [details] xml file used with previous patches. xml file for previous patch.
1) reading the description again, I should of used py-notify. 2) how can I organise putting an xml file up on the website 3) I will stop spaming bugzilla starting ... now :)
Created attachment 150951 [details] [review] three patches tarred, uses pynotify instead of a dialog. code change needed for XML file, until hosted file can be put up.
Hi Stephen, I appreciate you taking the time to attempt coding this! I can't comment much on the code (since I'm no guru), but I noticed something interesting: + if child.get("major") > pitivi_major_version: + pass + elif child.get("major") == pitivi_major_version and \ + child.get("minor") > pitivi_minor_version: + pass + elif child.get("minor") == pitivi_minor_version and \ + child.get("micro") > pitivi_micro_version: + pass + else: + return False Why did you make XML attributes thingies instead of just one XML value, and then splitting it with the dots? For example, wouldn't this be easier?: major, minor, micro = theversion.split(".") It would also remove the need for patching the "configure.ac" and "configure.py.in" files. Also, if it can help, I'd like to comment on the wording: + label=_("Check Version is Supported"), I would suggest the label to be "Check for software updates" (note: checkboxes don't use header capitalization; see http://library.gnome.org/devel/hig-book/stable/design-text-labels.html.en#layout-capitalization for more details) + notification = pynotify.Notification("Version not supported", + "Pitivi " + pitivi_version + " is no longers supported, " + + "please go to http://www.pitivi.org/ " + + "to get the latest version.") Here, I somehow wanted to add the explanation of "why", such as: "PiTiVi NEW_VERSION is available. Your version of PiTiVi is no longer supported. It will still work as usual, but will not benefit from bug fixes or new features." I'm not yet sure about how to phrase it correctly, but maybe something along those lines. I don't want to freak out users (or annoy them), just make them aware that they need to upgrade if they require support of some kind, etc. Now, there's also something else I was thinking about. Maybe we could have more than one version number in that XML file. Although we don't currently support more than one release at a time, I'm thinking ahead (in the distant future) when we *might* want to have a "soft deprecation" technique because we have "good enough" releases. We could have two variables: - latest released version: gives the "A new version is available, if you are interested" kind of message. - lowest "supported" version: gives the "Your version is too old and we cannot support it" message. Hope it makes sense.
Oh, and I uploaded version.xml to www.pitivi.org/version.xml so you can also test with HTTP.
>Why did you make XML attributes thingies instead of just one XML value I didn't really think about this so much, I guess it just comes down to me having something against doing text processing when I don't have too :) reading/dealing with pitivi_major_version is much nicer than version[0] also. >Also, if it can help, I'd like to comment on the wording The wording is much improved. >Maybe we could have more than one version number in that XML file currently it deprecates all versions before the <supported major= minor= micro= />. That is not to suggest it could not be done a different way. >latest released version this is a good idea if we want to inform users what the most current version is.
Created attachment 151021 [details] [review] patches updated, uses version.xml on the website. now emits "version-not-supported", "version-not-current" or nothing. to check this works you will have to modify pitivi/configure.py and change pitivi_version_*. you can use autoregen.sh to fix changes to configure.py. or git clean/ make clean.
Created attachment 151023 [details] [review] small change. re-add a try/catch block i removed while testing.
Review of attachment 151023 [details] [review]: This patch is no good it has the same needs as the power-management bug, which is a cross-platform api for desktop integration along the lines of pitivi.settings.desktop_message(title, message, image).
Is it possible/realistic to complete this for the upcoming pitivi release? I think it would be nice to have this feature in the first pitivi release that would be in ubuntu by default (and for quite a while, since it's a LTS). I'd sure help testing, especially if you make a git branch out of it (it's easier for me to just checkout I guess).
it is dead simple to do this. But it depends on my system branch, because the desktop messages have to be able to work on all enviroments in the future. alternatively, this could be put in as a 0.13.4 as a hack using a try, catch block.
set milestone to 0.13.5, as the system stuff wont be in the next release.
Okay, perhaps this can be revisited now that the system (power management) branch is merged. For one thing, I was wondering if perhaps part of the logic/processing could be outsourced to the server; that is, pitivi loads a page on pitivi.org that is a php script, passing along its version number as a "user agent" (or in the URL as a variable), and get a reply from the server. For example, pitivi would hit the server with "0.15", and then the server would figure out if that version is considered deprecated. If so, it would return False, and pitivi would know. An opportunity provided by this approach would be to have some usage statistics at the same time (ie: recording how many users are using what version of pitivi)... though if there was to be anything fancy like extrapolating data with Piwik, I doubt it would work without a browser... Just throwing some random ideas around.
Quick thought: maybe the most unobtrusive way would be to show a linkbutton widget/label to say "A new version (%s) is available!" in the welcome dialog.
I think outsourcing the logic to the server is unnecessary and doesn't give any advantages. If we want usage statistics I think it would be good to know more that just the version number. Think of resolutiuon, hardware, python version, gnome versions, basic usage data (codecs, filter...). So imho a plugin or subsystem to submit this data would work better from my view (like firefox already does) I started implementing my ideas here: https://github.com/palango/pitivi/tree/version-checker It basically knows three states. * Up to date: latest version is installed * supported: this version is still supported but a newer one is available * unsupported: this version is unsupported, update to something newer Some more thoughts: - should this be optional for distros? - showing info in welcome dialog sounds like a good idea - when should we load the information and should we cache it
Created attachment 211599 [details] [review] autoconf improvements This patch splits version information in autoconf and improves the AC_INIT macro. It's based on Stephens work but doesn't split the version in configure.py as it doesn't make much sense to me.
Review of attachment 211599 [details] [review]: not necessary
Sorry for the noise, Firefox didn't seem to respond, so I clicked a few times. I think autoconf can stay as it is. I filed an other bug to add the website to AC_INIT as https://bugzilla.gnome.org/show_bug.cgi?id=673763 Now to work on the bug itself. :D
Created attachment 211609 [details] [review] version check in startup dialog Mostly an update of Stephens code. Only the UI changed and the info is now shown in the Startup dialog. Also the format of the online status file is now easier. If we want to show that in the About dialog as well we have to find a way to store that information as we can't rely on signals then.
Created attachment 211661 [details] [review] add info to about dialog Improved patch to include version info in About dialog and make messages translatable.
Hi Paul, some thoughts regarding your patch #211661: - I don't think we should have an option in the preferences for this. Users don't (shouldn't) care, not if it is unobtrusive and does not prevent or delay startup. - Something feels slightly strange to me about the centered linkbutton at the bottom of the startupwizard, but I can't quite put my finger on it (maybe it's just that I'm not used to it). Do you have any thoughts regarding UI here? - You add the website URL to configure.ac, yet only use it in one place (startup wizard) instead of reusing it in the About dialog too. On the other hand, I'm not sure we really want that URL there in that case: we could also decide that the link should point to the download page or release notes or... hmm. Maybe that's just something I should do directly on the pitivi website now that I think of it ;) and perhaps we could use a URL such as http://pitivi.org/?pk_campaign=upgrade&pk_kwd=USER_VERSION_NUMBER ; that way, we get some stats about version numbers when someone clicks that button to visit the website. - The code has basically no exceptions handling... If it hits malformed syntax or some HTTP funkiness, I suspect it might choke. Please ensure it would not ever cause a traceback or delay application startup (as far as I can tell, your calls are async and should not block the UI in any way, though?) Have you tested this with some extreme scenarios (maybe using a restrictive outbound firewall that blocks/delays the connection)? For example, what happens if you receive the reply/version info way after the user closed the startup dialog or the about dialog? (yes, I like bulletproof things :) Generally, your implementation looks pretty good to me though!
Created attachment 212112 [details] screenshot I played around a bit with the user interface and finished with that. The button should be only the size of the image but I didn't get this to work with glade. If you have an idea, tell me :)
Created attachment 212113 [details] [review] patch v3 Thanks for your feedback! The new patch includes: - removed option from Preferences - Update and unify message in About dialog - Add error handling and logging I also tested the no connection and malformed syntax cases. You don't get any tracebacks or interface hangings. What's left to do - upload and update the versions info file to the pitivi website - decide which url we want to link to
The icon button is an interesting idea, but without text it might not be noticed at all by users, or (more likely) be ignored. The problem is when users don't see version numbers directly: since that icon/button might be shown for months (or the majoritoy of the year, each year) until the user gets a distro update, users will probably get "lazy" with checking the tooltip for that button. Hmm. What if, instead of putting things at the bottom or on the right side, we used a gtk infobar widget at the top of the welcome dialog? That way it would not have alignment issues (it would take the whole width, though we'd need to tweak spacing), and we could use the multiple importance color levels to differenciate between "new minor release available" and "your release is unsupported/end of life". This widget is already in use in many places in the UI (media library, project/render profiles warnings, etc.). Perhaps we can also load different stock icons depending on the update type: "software-update-available" and "software-update-urgent". > - upload and update the versions info file to the pitivi website > - decide which url we want to link to URL to use: how about http://www.pitivi.org/versions.txt ? Or releases.txt ? Translation string nitpick: > header = "<b>" + _("A new version of PiTiVi is available") +\ > " (%s)" % version["current"] + "</b>\n" ...Shouldn't the " (%s)" be part of the translatable string? Actually, the header string you're using in the welcome dialog is different than the one in the about dialog ("PiTiVi %s is available")... might as well make them exactly the same :)
The reason I didn't use a infobar is that I think it may be to intrusive, especially if, as you said, people have to wait for updates from the distro a long time. Maybe we could show an infobar but save it's state, so if an user closed it, it doesn't show up till a new release is available. about the url: releases.txt makes things clearer imho
Hmmm, I wish I had a screenshot to see how it really looks like with a thin infobar at the top. I'm not 100% sure that users would really consider this seriously "annoying" on a welcome dialog that is typically only seen for a few seconds at application startup. On the other hand, it might have less visual impact if it is shown permanently (like advertising that the eye learns to avoid). On the other hand, your idea of dismissing the infobar for a set amount of time might be the best. I can see some potential approaches - Show it once every X startups or every few weeks - Show it for 5 startups, then hide it until the next change in releases.txt Basically I want to avoid a silly "Close" (aka "Not now" :) button, yet at the same time don't want users to miss out on the version number label when it changes. On the server side, I changed the url to releases.txt as you suggested.
Created attachment 212314 [details] infobar screenshot What do you think about the infobar look? It's quite big, isn't it? Maybe we don't need the second line, so it would be good to show tell the user that the current version is unsupported.
Created attachment 212315 [details] infobar smaller
Indeed, the smaller version of the infobar is closer to what I had in mind; for the sake of the experiment, maybe we could forego the button (more compactness and centering) entirely, and set the dialog's border to 0 instead of 10 (and add that border/padding to the box that contains the rest below the infobar).
Created attachment 212455 [details] [review] patch v4 Next iteration with UI changes as proposed. This also implements the maximum of 5 hints for one version and adds a hint to the release file in docs.
Created attachment 212926 [details] [review] patch v5 replace some prints with logging calls
commit 20ad0a2c13d2d5c776a17fca9dc2f6545b68e81b Author: Paul Lange <palango@gmx.de> Date: Thu Apr 26 15:18:14 2012 -0500 Add a version checker Load version information from the PiTiVi website and check for updates. If a new release is available, it will be shown in the welcome dialog and the about dialog. Fixes bug #596864