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