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
