perl-unicode

Re: ANNOUNCE: Unicode::Collate::allkeys v 3.1.1.1

2003-05-15 07:30:04

On Wed, 14 May 2003 22:40:51 -0400
Ben Bennett <fiji(_at_)ayup(_dot_)limey(_dot_)net> wrote:

On Thu, May 15, 2003 at 08:00:48AM +0900, SADAHIRO Tomoyuki wrote:

How is about backward compatibility?
And I'm afraid since "customkeys.txt" is not a "8.3" name.

Ah... good points.  Thank you.

Well the 8.3 can be fixed by changing the name to sitekeys.txt.  It is
probably more clear that way too.

As for the backward compatibility, what if the install script for
Unicode::Collate::allkeys checks to see if there is an sitekeys.txt,
if so it can safely overwrite the allkeys.txt.  If there is not a
sitekeys.txt, then if there is an allkeys.txt it compares it to the
allkeys.txt that it will install and if they are different copies the
existing allkeys.txt to sitekeys.txt (maybe prompting the user, but
the default should be to copy it in case they are installing from
CPAN.pm).

That should be safe... worst case is that the user will still have an
old version of allkeys.txt in sitekeys.txt.  Which is kinda bad, but I
don't think they put a new version up recently.  The other choice
would be to keep signatures of the older official versions and see if
any of those match.  But I think that is overkill...

    Thoughts?

                  -ben

A user of Unicode::Collate::allkeys wants to
upgrade allkeys.txt, isn't he/she?
If it would be so, Unicode::Collate::allkeys
can overwrite an old allkeys.txt.

If someone wants to keep his/her allkeys.txt as it is,
he/she can determine to avoid Unicode::Collate::allkeys.

IMO, a bad thing is that upgrade of Unicode::Collate
would force upgrade of allkeys.txt silently.
If allkeys.txt is provided as Unicode::Collate::allkeys,
I don't think Unicode::Collate should need any change at present.

If Unicode::Collate still has some problem, please tell me it.

Thank you.
SADAHIRO Tomoyuki