On Apr 22, 2012, at 20:45, Bradley Giesbrecht wrote:
> On Apr 21, 2012, at 4:45 PM, Sean Farley wrote:
>
>> 3) uniform versioning
>>
>> For (3), I prefer ${last_known_version}-${date} but don't mind
>> changing this to something else as long as it's consistent.
>>
>> Open question: what to do about projects that never version? Assign a
>
> Regardless of what action we take here, I would hope that new "release
> versions" would always be higher then these smc versions.
> This should be the case if we use a alpha prefix for all smc_commit versions.
>
> Examples:
> version "1.0.1" becomes 1.0.1-{git,hg,github,svn}{smc_commit}
> version "null" becomes {git,hg,github,bitbucket,svn}{smc_commit}
>
> Note: when "null" is changed to a dotted numeric version this new version
> should be newer then {git,hg,github,bitbucket,svn}x.
I don't think we need to list the name of the hosting service (github,
bitbucket) in the version number. As for listing the version control system the
project happens to use, I'm not sure the user cares about that either.
Where you say "smc_commit" I hope you're not suggesting we use the actual git
or hg commit hash for the reasons I explained earlier about that not being
suitable for use in a version number because it is not an increasing number.
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
