[RT] cost of smooth migration and/or backward compatibility (was Re: [PROPOSAL] Plugin and themes naming convention)

[Ferdinand Soethe <fe...@apache.org>]

Ross Gardler wrote:

> It will cause problems for users having to change their local installs.
> This kind of thing annoys and upsets users. We would have to provide an
> alias facility for existing names.

Aren't we going a bit too far in our attempts to provide a smooth
transition?

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

Different story if we were talking about effects like upgrading early
Firefox versions. It _really_ made me mad how at some point each
upgrade would force you to reinstall all of your extensions and
reconfigure everything by hand.

But we are really just talking about changing a few names, if they are
using those plugins at all.

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.

I'd rather spend time on providing a smooth transition of user's
knowledge about Forrest than worry about update mechanisms for such
minor changes (or not make those changes for that reason).


--
Ferdinand Soethe

Re: [RT] cost of smooth migration and/or backward compatibility (was Re: [PROPOSAL] Plugin and themes naming convention)

[Ross Gardler <rg...@apache.org>]

Ferdinand Soethe wrote:
> 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.

Agreed.

...

>>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.

...

>>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.

 From a technical perspective you are 100% correct. However, we have to 
consider the community perspective too. Todays "basic" user is tomorrows 
"power" user, todays "power" user is tomorrows committer.

If we annoy the "basic" user by making it too hard to upgrade they don't 
become power users and we don't get new committers.

We have to balance technical vs. community issues, and this needs to be 
done on a case by case basis.

>>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.

Go for 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.

Agreed, in principle (meaning I hope to find the time to write such a 
script, in the meantime lets have new plugins conform to a convention).

> 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?

Personally I find such "surveys" a waste of time, but that could be 
because I don't know how to conduct meaningful surveys. I certainly 
wouldn't stand in the way of anyone trying to understand our users needs.

Ross

Re: [RT] cost of smooth migration and/or backward compatibility (was Re: [PROPOSAL] Plugin and themes naming convention)

[Ferdinand Soethe <fe...@apache.org>]

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

Re: [RT] cost of smooth migration and/or backward compatibility (was Re: [PROPOSAL] Plugin and themes naming convention)

[Ross Gardler <rg...@apache.org>]

Ferdinand Soethe wrote:
> Ross Gardler wrote:
> 
> 
>>It will cause problems for users having to change their local installs.
>>This kind of thing annoys and upsets users. We would have to provide an
>>alias facility for existing names.
> 
> 
> Aren't we going a bit too far in our attempts to provide a smooth
> transition?

Possibly, lets consider...

> 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.

> Different story if we were talking about effects like upgrading early
> Firefox versions. It _really_ made me mad how at some point each
> upgrade would force you to reinstall all of your extensions and
> reconfigure everything by hand.

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).

  > 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.

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.

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

> I'd rather spend time on providing a smooth transition of user's
> knowledge about Forrest than worry about update mechanisms for such
> minor changes (or not make those changes for that reason).

It's a balance. We need a smooth transition of users from one version to 
the next, otherwise they will never bother transfer their knowledge, 
they will simply move.

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.

Therefore, in my opinion asking the users to do it only causes 
unnecessary difficulty in upgrading for them. So in this case (and only 
this case) my conclusion is that either we do not change the names, or 
we change them and provide an upgrade script. Which we do depends on the 
merits of changing the names.

Ross

Re: [RT] cost of smooth migration and/or backward compatibility (was Re: [PROPOSAL] Plugin and themes naming convention)

[Ross Gardler <rg...@apache.org>]

Tim Williams wrote:
> On 2/12/06, Ferdinand Soethe <fe...@apache.org> wrote:
> 
>>Ross Gardler wrote:
>>
>>
>>>It will cause problems for users having to change their local installs.
>>>This kind of thing annoys and upsets users. We would have to provide an
>>>alias facility for existing names.
>>
>>Aren't we going a bit too far in our attempts to provide a smooth
>>transition?
>>
>>Is it really asked too much to follow a list of well
>>documented changes like adjusting plugin names?
> 
> 
> I didn't follow this discussion but if it's really that simple, why
> couldn't we automate that anyway?

Because we are still trying to decide if it is necessary or not, no 
point in automating if we decide not to do it ;-)

However, I think the intent of Ferdinands thread is in danger of being 
lost because of my mixing of concerns in my reply. Lets move the "to 
automate or not" part back to the naming vonventions thread and, in this 
thread focus on Ferdinands attempt to define boundaries between ease of 
upgrade and ease of development.

Ross

Re: [RT] cost of smooth migration and/or backward compatibility (was Re: [PROPOSAL] Plugin and themes naming convention)

[Tim Williams <wi...@gmail.com>]

On 2/12/06, Ferdinand Soethe <fe...@apache.org> wrote:
>
> Ross Gardler wrote:
>
> > It will cause problems for users having to change their local installs.
> > This kind of thing annoys and upsets users. We would have to provide an
> > alias facility for existing names.
>
> Aren't we going a bit too far in our attempts to provide a smooth
> transition?
>
> Is it really asked too much to follow a list of well
> documented changes like adjusting plugin names?

I didn't follow this discussion but if it's really that simple, why
couldn't we automate that anyway?
--tim