+1 for a changelog view.
The idea behind a two button upgrade is just as Branco explained, on my
production instance I´d only upgrade to stable but on my development I´d
upgrade to newest release just for helping out with testing.
This way maybe not everyone upgrades their production server to a not
stable release candidate.
Kenneth
On Fri, Dec 24, 2010 at 10:18 PM, VP<[email protected]> wrote:
For one thing, I don't think the 2-button suggestion is a good idea;
it's just another indirect layer of information that might not be
meaningful if the underlying mechanism is meaningful. Conversely, if
the underlying mechanism is meaningful, there's no need for the 2-
button solution. For example, if the release mechanism follows
strictly Massimo's rule that 1.x.0 is likely a feature-introducing
"big release" with potential big bugs, where as 1.x.9 is likely a bug-
fixing release, then users can make intelligent decision to upgrade or
not; so there's no need for 2 buttons. If this rule is not adhered as
intended, however, then 2 buttons do not help.
2-button solution doesn't solve the issue of making informed
decisions. It solves the issue of having an option between upgrading
to the next stable release, versus upgrading to the next release
candidate. The use-case is valid, and was outlined by Kenneth.
Inclusion of changelog is a good idea as well. The best place would be
the confirmation page for the upgrade action. It may also be
worthwhile to consider a single-button upgrade with a drop-down on the
confirmation page.
