Question concerning development port version using a fetch from SVN

Ryan Schmidt ryandesign at macports.org
Tue Nov 16 12:59:34 PST 2010


On Nov 16, 2010, at 14:53, Marko Käning wrote:

> I'm about to commit a kmymoney-devel to allow interested folks to stay at SVN HEAD for testing purposes.
> 
> Is it okay, if I use 'version' and 'revision' like this?
> 
> ---
> name                kmymoney4-devel
> version             SVN-HEAD
> revision            1197853

No. "version" should be the version you are fetching. If they don't assign a new version number all the time during development, then you may want to append their revision number to the version number. For example, if kmymoney 4.6 is currently being developed in their repository, then perhaps the version should be "4.6-1197853". I use this strategy in some of my ports... well, I used it in pure-devel until just recently. But I still use it in libhsplasma and PlasmaClient. Or you could append a date string. Some ports like graphviz-devel and gcc46 do this, though in this case these date strings are actually assigned by the project as they are part of their distfile names.

"revision" is an integer that starts at zero and is increased by one every time you want to make a change to the port that changes how the port builds but you do not want to increase the version. The revision is a MacPorts number; it should not relate to any upstream number, such as the upstream software revision number.


> fetch.type          svn
> svn.url             svn://anonsvn.kde.org/home/kde/trunk/extragear/office/kmymoney
> svn.revision        1197853
> ---
> 
> I wonder whether I could also skip "svn.revision"… Would the HEAD revision be used in this case?

Yes, if you omitted "svn.revision" MacPorts would fetch from HEAD. This would mean a user installing the port today would get different software from a user installing the port tomorrow (assuming upstream committed new revisions in between). This is not an acceptable outcome, so a port must not omit the svn.revision line. We want predictable software.




More information about the macports-dev mailing list