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. :)
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
