[haiku-development] Re: Begeistert warmup: Git migration, releases

  • From: "Ingo Weinhold" <ingo_weinhold@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Wed, 02 Nov 2011 12:11:11 +0100

Alex Wilson wrote:
> Replying to 3 emails in one:
> The sequential revision numbers really aren't that comparable. They're
> comparable in that a - b gives you the amount of changesets that one
> build is missing, but you don't know much beyond that.
> 
> Suppose a-b = 100. With 100 medium-large changesets, you can
> fix/introduce many bugs. However, with 100 changesets in graphics and
> network drivers, the code being discussed might not have been changed
> at all. Yes, developers will likely know about modifications they have
> made, but I don't read every commit that I pull, most people probably
> don't.

You seem to have a wrong idea how the revision number are usually used in 
practice. A not too uncommon bug report is like "bug in rXXX, used to work fine 
in rYYY". Usually that already helps to suspect a recent revision that changed 
something on the component in question. If you follow the ticket mailing list, 
you'll frequently see a ticket in which an early comment suggests a certain 
revision as the culprit on that basis (often being correct). Conversely, 
revisions can quickly be ruled out on that basis (if their number is greater 
than the tested one). That's all pretty helpful to narrow things down and it's 
a very simple mechanism at that same time.

> With more semantic versioning, you can quickly find out the sum
> of all changes that have happened between a and b, by reading the
> annotations of the version tags. There is definitely a convenience to
> numeric, monotonically increasing version numbers, but I think we can
> have that and more with 'real' versions. We get just a little bit more
> information directly from the version string, and it's easier to do a
> detailed comparison of two versions.

"Real" version numbers certainly wouldn't harm. On the other hand I also don't 
see any advantages of having those for the interesting use cases, though. 
Moreover generating those version numbers seems to be more complicated to me 
and probably needs to be done manually (in your example version numbers the 
"a3" component would be automatically available, but I don't know where you'd 
get the other ones from). At any rate, I don't see particularly good reasons to 
replace the sequential revision numbers.

CU, Ingo

Other related posts:

  1. Home
  2. haiku-development
  3. Archive
  4. 11-2011