Lack of deprecation period for short option changes

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

James Westby wrote:
> On (10/01/07 13:46), Aaron Bentley wrote:
> 
>>James Westby wrote:
>>
>>
>>>The same thing happens with bzrtools' version check, I tried to convince
>>>the Debian maintainer to turn it off entirely as there is not much point
>>>having package users warned, but it doesn't look like that is going to
>>>happen.
>>
>>I put that check in precicely because package maintainers were screwing
>>bzrtools up by assuming they could use an old version of bzrtools with a
>>new bzr.
>>
>>No package user should ever see that, because it should be impossible to
>>trigger if the package is maintained properly.
> 
> 
> and I wanted to take it out precisely because it is not being maintained
> properly, and Debian users had to spend a couple of months with the
> warning being output anytime they got anywhere near bzr.

Well, then there is more than one problem with the way the package is
being maintained, because you should not be able to install an old
bzrtools with a new bzr.

I'm diligent about keeping bzrtools up to date.  Bzrtools has never
lagged bzr by more than a week, and my current policy is to release
bzrtools when bzr goes into Release Candidate phase.

Packaging errors are not my fault.  Trying disable my safeguards so that
you can install untested combinations of bzrtools and bzr is the wrong
way to go.

> I'm not sure of the value of telling the simple package user of the
> difference when it requires action on the maintainer's part to fix it.

If the package maintainer was doing their job, you'd never be able to
install the wrong versions in the first place.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFFpUer0F+nu1YWqI0RAtONAJwMufkO0u9JMnSH7V1CvY8mTpachwCfeEK+
gaSS1AkyoBbOhv4rY3EYOE8=
=iqbg
-----END PGP SIGNATURE-----