Building #121

Closed
wants to merge 2 commits into
from

Projects

None yet

2 participants

@barijaona
Member

More consistent with naming conventions used till 2.6.0

barijaona added some commits Dec 27, 2012
@barijaona barijaona Upload binaries to Sourceforge & use VCS_NUM as a human readable refe…
…rence (rather than commit number or BUILD_NUMBER)

It is no more possible to host binaries at Github.
2821 was the last manually numbered build. From now, we use VCS_NUM handled by autorevision.
8282c85
@barijaona barijaona Updated instructions 0b8a9c2
@barijaona
Member

@dak180 : I think commit numbers are difficult to read for humans. I prefer using VCS_NUM as a reference.
Bundle numbers would therefore be more similar to those used before, like 2.6.0.2601.
What's your opinion on this ?

@dak180
Member
dak180 commented Dec 27, 2012

@barijaona it sounds like a bad idea to me; it is important to be clear about what the different version info is used for and not to use it out of scope.

VCS_TAG is the 'any human' readable portion of the the version string; users should get all the info they need just from this (see tag formating) so the second beta of 3.0.0 is tagged as v/3.0.0_beta2 and the third is v/3.0.0_beta3 and so forth. (This will pretty print as 3.0.0 Beta 2 anywhere a user will see it.)

VCS_SHORT_HASH is developer readable; it is meant to point to a particular revision in the repo for ease of testing/debugging.

VCS_NUM is launch services readable; it is meant to provide launch services with an unambiguous way to tell which of multiple copies of an app on the system is the latest version, it should not be used with anything else.

The confusion comes from the repo having previously been in svn where VCS_NUM and VCS_SHORT_HASH are effectively the same.

The important thing to remember is that for this system to work properly every beta, release candidate, and stable release needs a properly formatted tag.

@barijaona
Member

@dak180 I probably stated it incorrectly...
My changes do not affect at all VCS_TAG, VCS_SHORT_HASH and VCS_NUM.

They just make VCS_NUM to appear more prominently :

  • in CFBundleShortVersionString (which appears in Finder's Get Info and in the About box)
  • in CFBundleGetInfoString
  • in the names of the archives which are uploaded to the website.

And of course, from now on, we will use tags the way you described ... So everything should remain consistent...
But for human beings, decimal VCS_NUM is just more readable than hexadecimal VCS_SHORT_HASH...

In fact, I maintained VCS_SHORT_HASH alongside VCS_NUM in CFBundleShortVersionString and CFBundleGetInfoString. But I am tempted to suppress it there, because ordinary users should not mind at all about commit numbers...

Am I missing something important ?

@dak180
Member
dak180 commented Dec 28, 2012

@barijaona VCS_NUM should never be used anywhere but in CFBundleVersion in the info.plist; it being seen as 'human readable' is a lie (it does like to do that 😄).
VCS_NUM is actually a poor choice (though the best available one without a lot more hoops) for use in CFBundleVersion since the number there is supposed to go up for every build done, even if nothing has actually been changed.

What I think you are looking for is the number which comes after 'beta' in the tag; that is what users should be referring to (beta 4, beta, 5, even beta 5a if you want).

The next tag (if I have counted the betas right) should be v/3.0.0_beta7 which would result in a displayed version string of 3.0.0 Beta 7 :VCS_SHORT_HASH: where 3.0.0 Beta 7 is all a user should care about and :VCS_SHORT_HASH: is there to point devs to the exact commit for bug hunting.

VCS_SHORT_HASH should never be removed from CFBundleShortVersionString or CFBundleGetInfoString (both of which can be used to populate Finder's Get Info window) because (among other things) that is how they get into crash reports which is kinda important.

@barijaona
Member

@dak180 wrote :

VCS_NUM is actually a poor choice (though the best available one without a lot more hoops)...

I don't mind practicing some hula hoop 😃 but I really want something legible in CFBundleGetInfoString and especially in the .tgz filenames.
So we can either :

  • stick to VCS_TAG only for the .tgz filenames and hope nobody ever forget to tag before releasing
  • try to mess with Apple's agvtool
@dak180
Member
dak180 commented Dec 28, 2012

@barijaona the first part of CFBundleGetInfoString (before the comma) should always be the same as CFBundleShortVersionString (wierdness may otherwise happen) and CFBundleShortVersionString both must contain VCS_SHORT_HASH (if you want it in crash reports) and must not contain VCS_NUM if you want to be able to symbolcate crash reports after the fact. (Additionally the following stuff should never be in CFBundleShortVersionString: (, ), [, ],{ and } this list is not exhaustive.)

I do not recommend using agvtool; it brings nothing but pain and generally requires and assumes that there is a central build server which will do all builds for everyone.

@barijaona
Member

Thanks for the clarification.

I will fix it on these basis.

@barijaona barijaona closed this Dec 28, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment