1.6 release?

Juan Manuel Palacios jmpp at macports.org
Sun Nov 11 21:01:29 PST 2007


On Nov 6, 2007, at 3:41 PM, Ryan Schmidt wrote:

> On Nov 5, 2007, at 15:16, Juan Manuel Palacios wrote:
>
>> 	It's very pleasing to see the amount of work that has gone into  
>> base since our last release, but the negative side of that is that  
>> our current code delta between trunk and the last release branch is  
>> huge. Therefore I propose we make a 1.6 release with a new release  
>> branch from scratch, cut off from trunk ToT.
>
>> -) on the other hand, is there anything in particular anyone would  
>> like to see *NOT* released to the public just yet?
>
> I could think of one controversial change in trunk: the removal of  
> the "cd" command.
>
> I estimate[1] that we have 339 ports (about 8% of our 4353 ports)  
> that still use the "cd" command. These ports break without the "cd"  
> command. If I have some time I'll see if I can fix up some of the  
> nomaintainer ones; others should do the same if possible. If we find  
> that we're close to the date when we want to release 1.6 and we  
> still have many ports using "cd", we should delay removing the "cd"  
> feature.
>


	I greatly appreciate your effort to reduce the number of "cd  
casualties", Ryan!

	At 331 ports potential casualties and a ports tree sporting 4364  
entries, almost 10% of casualties is not that acceptable to me. Other  
than introducing workarounds for these Portfiles, or flat out shelling  
out when we can't avoid it, don't we have an alternative that'll give  
us the freedom Tcl's "cd" gave us, but without it's ugliness (changing  
the underlaying working directory of the Tcl interpreter, nasty!)?

	Kevin, at one point you said you'd give a MacPorts native "cd"  
equivalent some thought (at the pextlib level, like fs-traverse?). Did  
you manage to get anywhere? Landon, any idea you might have for us, to  
minimize the bloodshed?

	If there's nothing up our sleeves on this respect, then I'm afraid  
that for the time being we're gonna have to resort to shelling out for  
those ports that have no alternatives to get around calling "cd" (like  
smart paths usage).... but maybe we can do that as breakage reports  
start coming in...? thoughts? Should we delay 1.6 solely for these  
ports if we have no other solution for them?

	Regards,...


-jmpp




More information about the macports-dev mailing list