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