Why not upgrade? was (Re: [wp-hackers] Maintenance release, first gate of "is the issue major?")

[Bas Bosman]

> On 10/5/06, Peter Westwood <peter.westwood at ftwr.co.uk> wrote:
>> On Wed, October 4, 2006 8:22 pm, Lloyd D Budd wrote:
>> > This bug hunt is an awesome success and it is not over yet. While
>> > going to sleep last night, I rememberd a lesson learned in similar
>> > contexts. We probably should have been more conservative on what made
>> > it into 2.0.5 .
>> > http://trac.wordpress.org/query?milestone=2.0.5
>> Yes and no.  Most of those changes are very small.
Also the list is a little bit smaller, as this query doesn´t take tickets
that are still open into account.

The 2.1 release is still some time away so I´m quite happy that some of
these fixes made it into 2.0.5, because I´m actually facing some of those
bugs/issues now on my 2.0.4 blog. So even though they´re not critical, I´m
happy that for instance #3109, #3019 and #2663 (and ofcourse #3142) made
it in. And I´m sure others have similar issues they face fixed by 2.0.5.

>Snip<

>> > This is particularly relevant if you are interested in others such as
>> > Debian distributing WordPress.
>> > I don't want to have a 2.0.6. I want us focus on releasing 2.1.
>> Agreed - In general though maintenance releases for WordPress are
>> triggered by a security issue rather than anything else.
As far as I know when a security issue in a Debian package is discovered,
a fix for that particular issue for that particular version is included.
So if Debian starts including 2.0.5 in stable for instance and a security
bug is found, they´ll patch that bug. They won´t "upgrade" to the then to
be released 2.0.6. The 2.0.6 package will still have to follow the normal
path to get included in a future (re-)release of Debian.

>> I think we also need to be aware of the fact that in general our
>> end-users
>> don't always upgrade straight away and we need to understand why:
>> It is because maintenace releases are difficult to upgrade to -
There is work being done for 2.1 to reduce that somewhat. Tickets #2616
and #2447 for instance.

>> Hopefully
>> this is simplyfied by Mark, myself and others who provide diff files and
>> instructions for generating them.
> Provide diff files: Unfortunately, don't image the impact is that
> great as you are getting close to people that likely already have a
> handle.
I agree, although this service is invaluable to people who want to upgrade
and have made modifications to core on their own. ("hacked" default
templates for instance)

>Snip<

>> It is because people are just too lazy - I can see from the small sample
>> of users who have installed my Verson Check plugin that there are people
>> out there still running 1.5.2/2.0.1/2.0.2/2.0.3 even with a big flashing
>> warning  on every admin page!
> I think your work with Version Check plugin is very important and I
> look forward to it or some variant being included in core.
>
> I think it comes done to convenience. I think a nag to inform is an
> important small step, but  any thing short of click to upgrade is
> probably not going to be the medicine.
Most non-developers I know have an "install and forget" way of working. If
it works they don´t look into it. Therefore most of them won´t even know
that there even is a newer version out there than what they´re running.

The group that uses your Version Check plugin is most likely already more
savy with computers than most users. And if even they can´t be bothered to
upgrade...

Therefore I´m a big fan of including some of this functionality into core.

I´d even go as far as to have the admin area disable certain functionality
(writing posts for instance) when a security release is released (don´t
bother visitors, only backend users) to "force" people to upgrade. This
functionality should be on by default, but give people a configurable
option to turn it off. Then they have to make a conscious decision not to
upgrade.

Any suggestions on this?

Kind regards,
Bas Bosman (Nazgul)