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

[Rainer Müller]

On 2009-06-07 00:27, Ryan Schmidt wrote:
> 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.

It is marked as deprecated on trunk only which is going to be 1.8.0. The
first release with this deprecation will be 1.8.0, so I don't see any
problem with that.

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

What is the problem with the deprecation being on trunk? This is going
to be 1.8.0 after we branch it off and as such it gets new features. Now
this code is living there to get tested.

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

I would just say it should be removed in the next minor release, in this
case 1.9.0.

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

It is trunk, it can do whatever it wants. This is not released and users
of trunk should be aware of that. I hope that maintainers using trunk
still have another prefix with 1.7 to test their ports there as well if
in doubt. If you target 1.7, ask lint of 1.7 what to do.

The new option will be available as of 1.8.0 and this is also the moment
when the old name should be avoided in my opinion. Therefore lint should
warn in 1.8.0 which is currently trunk.

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

Other candidates for renaming would be ${applications_dir} and
${frameworks_dir} as they should rather use "path" to instead of "dir"
be consistent with other variables we use. See for example ${workpath}
and ${workdir}, ${filespath} and ${filesdir}, and so on.

Rainer