On Fri, Jun 05, 2009 at 04:25:45PM -0500, Ryan Schmidt said: > > On Jun 5, 2009, at 16:05, Bryan Blackburn wrote: > >>> As with svn.revision, I must ask: why have we set up port lint to >>> state >>> that livecheck.check is deprecated, when *it is not deprecated yet*? I >>> love that we have fixed the naming of svn.tag and livecheck.check, >>> but we >>> *cannot* mark an old feature as deprecated until we release a version >>> of >>> the software containing the replacement feature. >> >> It's only deprecated on trunk, but lint on the server of course isn't >> just >> 1.7. If you're suggesting we don't deprecate it until 1.8 is released, >> then >> the deprecation stuff wouldn't be all that well tested. > > 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.
True, but the only other avoidance of a deprecation that I recall was by me, and I used if statements so that it works with both 1.7 and 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. So technically not deprecate until 1.8.1 (or X.Y.1) by backing it out for now, then re-adding to trunk and merging to the 1.8 branch after release? I suppose we could keep a ticket around for tracking such deprecations needed for each major release so they aren't otherwise lost. Bryan _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
