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

[Ryan Schmidt]

On Jun 6, 2009, at 11:25, Rainer Müller wrote:

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

1.8.1 would be a more appropriate release in which to mark the old  
commands as deprecated, because the new commands will not exist until  
release 1.8.0. My objection is that if we have new synonyms for  
existing commands that will be available in release "n" (i.e.  
svn.revision and livecheck.type that will be available in 1.8.0),  
then we must not mark the old commands as deprecated until release  
"n" has in fact been released. We can mark them deprecated in release  
"n+1" (i.e. 1.8.1 or 1.9.0). It's not like the old commands svn.tag  
and livecheck.check have been removed. There is absolutely no problem  
with ports continuing to use the old svn.tag and livecheck.check in  
MacPorts 1.8.0. On the other hand, there is a major problem with  
ports using the new svn.revision and livecheck.type in MacPorts  
1.7.1: the port will not work at all because those commands do not  
exist yet. Therefore, while there are still users using MacPorts  
1.7.1 (i.e. until MacPorts 1.8.0 is released) we should not recommend  
that anyone replace svn.tag and livecheck.check with svn.revision and  
livecheck.type, respectively.

Just so we're clear, according to the wikipedia:

http://en.wikipedia.org/wiki/Deprecation

"In computer software standards and documentation, the term  
deprecation is applied to software features that are superseded and  
should be avoided."

svn.tag and livecheck.check are NOT superseded and should NOT be  
avoided (and in fact, must continue to be used) until MacPorts 1.8.0  
is released. Thus, these features should NOT be marked as deprecated  
until 1.8.0 is released. That is the point I'm trying to make here.

I don't really care if the deprecation warning is put into 1.8.0  
right before its release, except that in the interest of having code  
tested before release, I would expect the code to live on trunk for  
awhile and become a part of the next release, like any other code.


At some point in the future, maybe release "n+5" or 6 months down the  
road, the old commands and the lint check can be removed entirely.


> 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

That would probably cut down on the number of people committing this  
change before 1.8.0 is released. But why should lint print a message  
for something the maintainer *shouldn't* do yet? Thus far, lint has  
only mentioned things the maintainer *should* do right now, which  
seems like the way it should be.




I don't want to make too big a deal about this deprecation situation,  
since there haven't been that many slip-ups, and we've caught them  
fairly quickly. And I don't expect we'll be deprecating too many  
other options soon. But I just don't think we've handled deprecating  
options in a way that makes sense, and I'm trying to explain why I  
feel that way and to suggest a way that makes sense to me. :)