github port group

[Bradley Giesbrecht]

On Apr 22, 2012, at 7:05 PM, Ryan Schmidt wrote:

> 
> 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.

Fine, with ${version}-date we can always increment revision.

But want about when no version is present. Without some prefix yyyymmdd makes a real high version number.


Regards,
Bradley Giesbrecht (pixilla)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2763 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20120422/e868a641/attachment-0001.bin>