Lack of deprecation period for short option changes

[James Westby]

On (10/01/07 12:15), Martin Pool wrote:
> To support SHORT_OPTIONS we might need a special object that stays in
> sync with the new stuff.  What did your plugin do with it, James?

Just registered some short options, I wasn't aware there was another
API.

  working_tree_opt = Option('working-tree', help="Use the working tree")
  Option.SHORT_OPTIONS['w'] = working_tree_opt

Pretty easy to sort out, but it does mean 2 different versions. Though I
have two versions already due to deprecation of BzrNewError in 0.13.

Deprecation is good for API users like myself, but as a user it is
really irritating. The deprecation warnings that are spit out every time
the deprecation is used can get annoying. And if just loading the plugin
triggers the warning even

  $ bzr <TAB>

triggers it here (zsh) printing the warning over any half finished
completions.

Would it be feasible to have something like

  @suppress_deprecation_warning

that could be added to the call? This would allow me the API user to
suppress the warnings and not irritate me the user, while still forcing
me to note that it is up to me to switch. This still forces me to have
two branches eventually though, so probably some mystical code to check
at runtime would be better.

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.

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