Community
Participate
Working Groups
We should by default select the location we will use for installing updates, and only show the install wizard page if needed. The default "rules" are: * always install updates into the same location the currently-configured feature resides in * if we are installing a feature, there are not configured versions of it, but there are unconfigured version, we pick the location of the unconfigured features (latest version of it) * if we are installing a feature and there are no other loca versions, it is installed into the "product" site We only show the wizard site selection page if the default location cannot be used (cannot be written, is out of space, etc).
If we cannot tell if there is enough space (required size computation returns - 1), we have no choice but to show the page it in that case. If we cannot tell if we have enough space to install then we should allow new location to be created. Ie. treat it is out-of-space condition. But we need to make sure that the only choices we offer are the default site for the feature we are installing (based on the other rules), and private site(s). Core should probably have an API for this (isProductSite(), isExtensionSite(), isPrivateSite () or something like that).
released core code (IConfiguredSite isProductSite, is ExtensionSite, isPrivateSite) Also fixed isUpdatable. Maybe, still need to exercise validation as isPrivateSite will return true for any private site
Dejan, I am having second thought about this whole business of not knowing the install size and showing the location selection page. It seems like the user will be more confused sometimes seing the page, other times not. Users are used to being shown default location and selecting. So I am soliciting your UI opinion on this. There are 2 basic scenarios that we are talking about: (1) the "one button click" update off the Help>Software Updates (2) the "advanced user" install using the update manager It seems like for scenario (1) we have no business searching for updates to features that are on r/o installs (they are r/o because someone is administering the damn too for me). So perhaps the rule should be: search only for updates to features on sites I can write to, and then just assume there is space and do not offer the user the choice. For scenario (2) the "advanced" user is used to being offered a choice by native installers, and maybe we should just work the same way. That is, always show the page with the correct (default) site preselected, plus also show any private sites, and allow a new private site to be created vie the [New] button. That way the "naive" user has a somple path, and the "advanced" user has a consistent path (page always there, correct location preselected, but can choose new one, and we enforce the rule that says the only alternate location for the feature is a private site (not product or extension)) Comments?
I agree, but I would leave case 1) for post F1 discussions when we finalize what a one-click-update experience should be. In should definitely be simpler than in 2). Also the assumption must be that updates to products must go into product tree For F1, I agree that we should have experience as defined in 2).
Implemented.