forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ferdinand Soethe <ferdin...@apache.org>
Subject Re: [RT] cost of smooth migration and/or backward compatibility (was Re: [PROPOSAL] Plugin and themes naming convention)
Date Mon, 13 Feb 2006 11:20:40 GMT
Ross Gardler wrote:

>> Is it really asked too much to follow a list of well
>> documented changes like adjusting plugin names?

> No, but the reality is that people do not follow a simple list of 
> instructions, they ask questions and take our time up, or worse still,
> they move away from Forrest because it is too much work.

OK. I accept that reality (being part of it myself :-)) so it may be better to
write a script to migrate them automatically.

OTOH this very reality is also a good argument for investing time to
make the system as consistent and logical as can be to avoid
questions and user problems in the long run.

> Well, that is *exactly* what would happen if we changed plugin names.
> forest.properties would have to be updated and plugins would have to be
> downloaded and installed again (not always done automatically, depends
> on users set-up).

Well no. What upset me about Firefox was not the fact that I had to
update everything. What I hated was that I lost all my configuration
settings and found no real way to carry them over.

I agree that having to download manually all pplug-ins is a bit of a
drag but consider how few people will have to do that.

>> And compare this to other side effects our recent developments have had
>> or will have. Not saying that they are wrong (!), but consider that the
>> changes planned or already done will invalidate a good part of people's
>> knowledge of how Forrest works.
>> And the time it well take them to
>> learn about 0.8.

> 0.7 sites will run (almost) unchanged in 0.8 This is what we are trying
> to achieve. There is no *requirement* for users to use the new features,
> they can stick with the old methods if they like.

Well, the example above deals with a power user situation. So let's
stick to that. Which also means that they don't run Forrest right out of
the box and will have to learn about the internal changes.

> The right way, IMHO, is to deprecate old functionality to provide a
> smooth migration from one version to the next rather than to force users
> to learn a whole bunch of new things in order to upgrade.

Yes, but the speed we are going means that there are limitations to
this approach. Because even if we maintain Forrest 0.7 skin
functionality in version 0.8, it only means that we delay the need to
upgrade.

Unless you are prepared to stick with 0.7 functionality and all of its
shortcomings (which there are a few) forever, you get some more time
to adjust to the new system. (Which is a great service, no doubt) But
let's be clear: using Forrest these days is really about learning new
things all the time.

> Of course, sometimes this does not make sense, we need to weigh up each
> individual cases on its own merits.

My opinion is we should accept this and admit that
we are not even 1.0 and we don't want to burden us with too much
backward compatibility issues before we get there.

> It is trivial to either write an alias facility for the few plugins we
> already have, or to write a script to update existing forrest.properties
> files. In fact it will take less time for one individual to do than for
> the community (as a collective) to answer the resulting user queries.

Great, so let's do it.
My whole point was that it should be either that or let the user's do
it on upgrade. Not use this as a reason not so clean up
inconsistencies.

Btw. I really think that a survey of Forrest users, their use cases
and expectations would very useful for discussions like that.

Perhaps we can put a questionnaire on the user list?

--
Ferdinand Soethe


Mime
View raw message