[51868] trunk/dports/devel/git-core/Portfile

[Rainer Müller]

On 2009-06-05 23:25, Ryan Schmidt wrote:
> All I'm saying is that the situation we have is not working. This is  
> not the first time someone has run "port lint", thought they should  
> change something because "port lint" said it was deprecated, but this  
> ended up breaking the port for anyone not running trunk.
> 
> My vote would be for "port lint" not printing a message until after  
> 1.8.0 is released. That would avoid the problem. We can mark these  
> things as deprecated after that, and make the message appear for  
> users in 1.8.1.

I don't understand why 1.8.1 would be more appropriate than 1.8.0. Such
a bugfix release could happen at a random time when some bug is
discovered which needs a fix. This could be one day after release,
three months later or not at all.

But that would mean it would probably print this message at last in
1.9.0, and could then finally be removed in 1.10.0. Do we really want to
delay this for another major release?

Even if we do a one-time replacement on the official tree, others will
probably still use svn.tag and livecheck.check when developing new
Portfiles until 'port lint' emits a warning about this.

Would it help if the warning includes the version number?

  Warning: Option 'svn.tag' will be superseded by 'svn.revision' as of
  MacPorts 1.8.0

Rainer