I'm not keen on the 2 button approach -- can you imagine a 2 button release for python? Nevertheless, it does potentially simplify the gathering of an important stat, which is how many users are testing the new release. With historical data, this could give other users a metric on how well used any given release is.
On Dec 24, 5:24 pm, Kenneth Lundström <[email protected]> wrote: > +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. > >
