Documenting unreleased features in the guide
Ryan Schmidt
ryandesign at macports.org
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
such.
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