Lack of deprecation period for short option changes

[James Westby]

On (10/01/07 15:48), Aaron Bentley wrote:
> 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.

I think you are doing all you can.

bzrtools is actually maintained by the utnubu team, who I believe were
aiming to just sync back their packages from Ubuntu, but that hasn't
been happening.

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

This makes sense.

> 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 also seems reasonable, and is going to put a lot more pressure on
the maintainer to update in a timely manner. Maybe they don't want to
commit themselves to this.

The solution here is obviously to have an attentive maintainer for the
package. I'm not sure if this is going to happen soon though.

Thanks,

James

-- 
  James Westby   --    GPG Key ID: B577FE13    --     http://jameswestby.net/
  seccure key - (3+)k7|M*edCX/.A:n*N!>|&7U.L#9E)Tu)T0>AM - secp256r1/nistp256