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)
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
