Lack of deprecation period for short option changes

[Aaron Bentley]

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

James Westby wrote:
> On (10/01/07 15:08), Aaron Bentley wrote:
> 
>>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.
> 
> 
> You are a great maintainer for a very useful package, I'm not trying to
> suggest otherwise. I am just trying to cope with the situation that we
> have in Debian where the maintainer has not been very reliable recently.

I've had this problem with bzrtools maintainers before.  At their
suggestion, I started releasing bzrtools in parallel with the bzr
release candidate.  Seems like that's not enough, but I don't know what is.

>>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.
> 
> 
> If you are sure that bzrtools can't work with a mismatched version of
> bzr why don't you just disable the plugin entirely?

I am not *sure*.  Technically, if bzrtools is a single release older
than bzr, and if bzr doesn't violate its deprecation procedures, then it
will work.  But of course I can't know what bzr 0.15 will be like when I
release bzrtools 0.14.

Beyond that, there is no guarantee, so bzrtools does disable itself.

I don't think it's a good idea to run an older-by-one bzrtools.  And
previously, people would complain about the deprecation warnings,
without realizing it was because bzrtools was out of date, so I added
the version warning.

>>>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.
>>
> 
> 
> We agree on that.

What I mean is that the bzrtools 0.11 package should depend on bzr ( >=
0.11 ) and bzr ( << 0.12 ).  That used to be the policy, but I see it
depends on bzr ( > 0.9 ) instead.

That bogosity seems to have been introduced in this bugfix:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=382561

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

iD8DBQFFpVES0F+nu1YWqI0RAvBZAJwN1yAYCZnzgFGDB5ITMsJpEKZobgCeNZdp
uyTTp2CQxdMahQmFFdY13gI=
=Gyb4
-----END PGP SIGNATURE-----