NetBeans71PatchingProcessReview

Revision as of 15:22, 26 April 2012 by Psomol (Talk | contribs)

Contents

Review of Patching Process in NetBeans 7.1

Based on feedback of !NetCat72 community we realized several problems and possible confusions from users point of view while distributing patches and releasing minor releases of NetBeans simultaneously - tracked as Issue 211076.

Plan

7.2

  • Install updates of Autoupdate with other updates together, suppress preference Autoupdate to other module - Issue 211734
  • Run installation of updates on background and just show progress in the status line - Issue 211735
  • Suppress license agreement on licenses which was already approved - Issue 211736
  • Show notification about available update immediately when activated any feature (e.g. PHP Support) - Issue 211737
  • UC can describe own content and show it somewhere in IDE - Issue 211741
  • Improve About box to show if IDE is up-to-date to given state (e.g. All plugins up-to-date to 7.2 Patch1) - Issue 211796
    • Link to all resolved bugs in given patch

Post 7.2

  • When there is a new release (point or full), download installer on the background and run it from NetBeans. This is similar to Firefox - Issue 211739
  • Allow to launch IDE directly from installer - Issue 211740
  • Installer installs a upgrade (i.e.replacement) of older IDE installation - Issue 108684

Declined

  • Improve creating NetBeans splash and use text field instead of graphic, text read from bundle - Issue 211076
  • Reduce patching on showstoppers only and publish minor releases as upgrades (i.e. new bits with own installer)
  • Either install updates of disabled modules, or install latest version of module when activate a feature

Why?

Patching in NetBeans 7.1 from users point of view

First start of 7.1 IDE
  • Fresh install of NetBeans 7.1
  • An user can see a notification 1 update found


Update of Autoupdate Services found
  • The update contains an update of Autoupdate module


12 other updates found
  • After installation of update of Autoupdate and restart IDE, user can see notification that rest of updates is read for update
Content of updates



14 updates found
  • Fine. All updates are installed and s/he can start using IDE.
  • Create a Java Application. Because it's the fresh IDE, Java feature is still switched off. IDE activates Java feature.

==> IDE is semi-updated now. Platform is up-to-date but Java has not been updated yet.

  • S/he does coding, testing, whatever.
  • On the next round checking for updates (once a week as the default) another bunch of updated will be offered to user.
Update of Java feature


Status of Java feature
Subversion plugin was patched
  • An user would like know if Java feature was updated or not. Opens Plugins, switch to Installed tab and select Java feature but there no indication about the update.
  • After switch into Showing details view and mark e.g. Subversion plugin. In plugin description is a note about !NetBeans7.1PatchesInfo


New release is available
  • Notification of available upgrade IDE


Problems

  • Autoupdate doesn't update disabled modules
  • Missing a solid feedback about the patch what is being installed.
  • Missing a evident mark what release+patch is currently installed (e.g. NetBeans7.1 with Patch1 included)
  • Confusing installing updates in several steps
    • First step: Install update of Autoupdate
    • Seconds step: Other updates of active modules
    • Third steps later: Further updates of modules what became active recently



General UEX Comments

(Petr S.)

This is to summarize the ideal state of install/update functionality from general user's point of view. We should expect users to demand functionality comparable to other current popular software packages (not just IDEs), though taking into account NetBeans specifics like its wide-ranging modularity.

Users generally expect:

  • the least obtrusive process possible (no UI interaction unless absolutely necessary)
  • download size to be the minimal possible + installation time to be as short as possible
  • no after-install steps necessary; everything should work unharmed as before without the necessity of any user's intervention
  • but, users need to stay informed unobtrusively but clearly that something important is to happen or has happened (like e.g. a silent update). This information should remain discoverable if it relates to persistent changes (a temporary notification can be missed)
  • and, at any time the information about what is the current state of the installed NB as a whole and what modules have been installed/updated should be clearly obtainable. Users need to know what version of NB they are using, i.e., whether an update has upgraded the installed NB to any specific version that is known to exist (e.g., when there exists a downloadable installation package denoted 7.1.2, users need to understand clearly whether their 7.1 installation after updates becomes 7.1.2 or not, whether it is at all possible to achieve 7.1.2 state by updates, etc.)

To more specific use cases:

Major installs

Major installs (presumably 0-dot or 1-dot versions) where it is understandable that the current installation should not be silently updated due to possible notable changes in UI or functionality:

  • availability of new version should be unobtrusively announced (bubble notification, constant message in About dialog and/or Plugins center) and quick link to launch the installer should be provided.
  • necessary user interaction should be minimized as much as possible, whatever can be deduced automatically should be done so (choice of source URL, installer version, OS, package extent to fit the currently installed version etc.). Nevertheless the user need to have the option to change settings if she wanted.
  • after install it should be possible to import previous state (default option, but possible to avoid) so that everything works as it did before right away (with the only exception of functionality that was incompatibly modified between the old and newly installed version)
  • the information about important changes should be obtainable

Minor installs and updates

Installs of 2-dot versions, patches, fixes and other limited updates, that are not intended to modify significantly the IDE usability and functionality, should require minimum user interaction:

  • availability of important patches/updates should be unobtrusively announced (bubble notification, constant message in About dialog dialog and/or Plugins center) and quick link to launch the background update should be provided.
  • necessary user interaction UI should be minimized, i.e., limit user interaction only to confirmation of licenses only if they have changed since previous module version
  • installation should run in background (not blocking the IDE). Successful finish should be unobtrusively announced (bubble notification, updated version information available in About dialog and/or Plugins center)
  • installation of all available patches (unless user decides otherwise) should be done once, i.e., it should not happen that right after one install another batch of updates is immediately announced
  • in Plugins center provide clear indication which modules have been updated and for which modules an update is still available. For each module it should be possible to find out what has been changed in its update(s). A global list of changes since fresh install should be available. Ideally each module should be marked by a NB version number, informing about the version of NB in which the module in its present form is officially distributed.

Practical Implications

The ideal described above is not easy to achieve for technical and conceptual reasons, like:

  • due to extensive modularity and ergonomics (possible installed/uninstalled and active/inactive state of modules) the definition of what the "current version" of the whole installation is is not straightforward
  • even if two installations, one fresh from installation package, another updated through update center, have all module versions equal, the two installations are effectively not equal. Differences are caused, e.g., by inclusion of external binaries that get installed through standalone installer but can not be updated through update center

Despite of the problems we should better keep improving things to take the UEX considerations described in the previous section into account.

See the section Plan above for the most imminent improvements under consideration.

Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo