On May 18, 6:50 am, Kornel Benko <[email protected]> wrote: > Am Dienstag 18 Mai 2010 schrieb Bruno Postle: > > > On 18 May 2010 09:42, Kornel Benko > > > > at least in this CMakeLists.txt the value of V_PATCH was hardcoded to > > > "0". > > > > Changing it to the revision gives me what I wanted. > > > Please don't change the name of the tarball (or the folder inside it), > > this will be a pain for packaging, and will have to be switched back > > every time we do a formal source release. > > I don't understand. If we append the revision, then the package name is > automatically changed too.
Yes, but it's the same as we did before with SVN. I realize only now that you were talking of the third or patch number in the complete version string, and not of the fourth. The policy with version number is that there are four dot separated elements to it: - major: the year of the release - minor: a sequential number of release within the year, odd being a development snapshot and even being a public release to production - patch: incremented in case we must re-release the package (e.g. security vulnerability, or if there have been enough post-release improvements such as translations to warrant a re-release) - revision numer: this is where the SVN revision number would come in. Meaningless but not disturbing for public releases to production, helpful for feedback / bug reporting on development snapshots. Put in the Hg rev-nr in the fourth element instead of the SVN rev-nr and it will work well for all packages generated from the same repo. If the repo is a fresh clone of the SF central repo, the likelihood is very high that .1234 will stay .1234 across different packagers - important for distribution / package managing software. On the other hand, if you've played with the repo (e.g. you're a developer), then your .1234 will be different than mine .2345 - not a problem if these packages are only part of the dev process and not distributed. It would generate confusion to distribute them to the general public (the package manager may complain about a smaller version number / older version when this is not the case), so particular care must be taken when preparing tarballs for distribution. An (unfortunately manual) line of defense against such confusion is to use the changeset ID in the "about dialog" and similar strategic places from where it can be reported by the user. The changeset ID is consistent across repos but unfortunately it is not incremental so does not work nicely with package managers. For platforms without package manager (e.g. Windows and OSX) I'd be tempted to use the changeset ID to name the installer - however it is not very user friendly to ask them to report an eight digits hex number. An alternative would be builder & rev-r (e.g. Hugin-2010.1.0.4033-Harry) with builder being a proxy for the repo from which it was built. Maybe there is a possibility to tap into the [ui] username variable inside .hgrc and make a shortened string out of it. The first two digits of each word excluding the email address, so in my case it would become Hugin-2010.1.0.YuLe-4033 and in your case it would become Hugin-2010.1.0.KoBe-4033. It is easier to explain a package manager warning with "you used a package from another builder" than with "mercurial internals and our less than perfect build have given it an out of sequence number". Yuv -- You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/hugin-ptx
