Documenting unreleased features in the guide

Ryan Schmidt ryandesign at
Fri May 23 04:56:43 PDT 2008

My thoughts are that I wouldn't branch the guide and I wouldn't put  
conditional anything in the XML to generate two documents. Keep a  
single guide. Do, or do not, indicate which version of MacPorts each  
feature was introduced in.

I like the php documentation because for every php function it says  
which version of php it was introduced with. For some functions, it  
has a kind of changelog at the top, showing that in, say, version  
4.3.0, the function was added, and in 5.0.3 it was changed in this  
and that way. This is great because sometimes your web host has an  
older version of php installed and you need to know that you can't  
use a function in a certain way, or at all.

MacPorts is much smaller in that it has much fewer functions  
(commands), and also prior versions aren't useful in that once  
someone syncs their ports tree, they pretty much have to be running  
the current MacPorts version so they don't run into syntax errors and  

All this is to say that I think it's ok if we just continue  
documenting new trunk features in the guide without further ado. If  
we could add an "introduced in" version number next to new things,  
that would be great, but isn't essential.

More information about the macports-dev mailing list