Default revision of 1
Blair Zajac
blair at orcaware.com
Tue Oct 10 13:55:05 PDT 2006
I don't see the need to have revision numbers be integers.
And I'm not suggesting that non-integer revision numbers be committed into svn.
I do think that only released, integer revisions should be committed.
And using branches for maintaining individual Ports will be a pain, although you
could switch those specific directories to a branch. But even then, that won't
work for people who don't have commit rights to our Subversion repository, since
they won't be able to commit a development version on a branch.
So having non-integer revision numbers seems to be the easiest way.
Regards,
Blair
Kevin Van Vechten wrote:
> I'm saying revisions should be interpreted as they are in Subversion --
> monotonically increasing serial numbers. You can't agree with me _and_
> want to "leave space for development". Trying to arbitrarily pick
> revision numbers, encode special significance into them, and avoid
> collisions with other developers is fraught with peril. Revision
> numbers indicate that something about the Portfile has changed aside
> from the name and version. The decision as to what's development or
> what's stable needs to be made out of band with respect to revision
> numbers. Again, using Subversion as an analogy, that's what
> tags/branches are for.
>
> - Kevin
>
> On Oct 10, 2006, at 12:54 PM, Blair Zajac wrote:
>
>> Kevin Van Vechten wrote:
>>> Revisions should be a monotonically increasing serial number (think
>>> SVN revisions) indicating the revision of the Portfile.
>>> The purpose of the revision is to provide a unique primary key for
>>> every portfile: {name, version, revision}.
>>> - Kevin
>>
>> Right. And it would be good to have a space for development
>> versions. With RPMs, the default revision people use is 1, so if I
>> want to roll some beta RPMs out to people, I commonly use 0.01, 0.02,
>> etc. It gives me a lot of space to get issues fixed, and then when
>> I'm happy with it, I bump the revision to 1.
>>
>> Regards,
>> Blair
More information about the macports-dev
mailing list