On 20/03/12 19:59, Jesse Becker wrote: > On Tue, Mar 20, 2012 at 14:52, Daniel Pocock <dan...@pocock.com.au> wrote: > >> On 20/03/12 19:27, Bernard Li wrote: >> >>> I don't really want to make a big deal out of this but I thought it >>> was long agreed that we would tag a release (eg. 3.3.2) and that would >>> potentially be our "Release Candidate". If everything is fine, we >>> will just release as is otherwise we will discard 3.3.2, bump the >>> version to 3.3.3 and repeat the cycle. >>> >>> >>> >> I remember that discussion too, and I think was pushing that same >> argument - that it is easier to burn release numbers than to worry about >> suffixes >> > I agree. So long as the numbers only increase, the minor release > number is basically irrelevant. > > >> That discussion was held in the days of SVN, when making a tag was quite >> painful >> >> Now we have git, >> - people can make local tags (almost like bookmarks?) whenever they like >> - you can make two tags on a single commit, because tags are like >> symlinks (e.g. 3.3.3rc1 and 3.3.3 both point to the same commit) >> >> This comes back to my earlier comments: the tags I have made today (e.g. >> 3.3.3dp1) are not intended for packaging, it is just a helpful reminder >> for me to know how I built the tarball for people to test. I think it >> is a useful phase in the release process. >> >> Once we get to the point where people want to test proper versioned >> RPMs, then we use a real tag (e.g. 3.3.3) and if the RPMs are proved to >> be dodgy after that tag is made, then we burn the version number and try >> 3.3.4 >> > Now, with RPM releases, it may not be that bad. RPMs inherently > support a "release" (in the RPM lingo), which is the least significant > digit in the complete version number. If we have a ganglia release of >
What is the intention of that release number though? Is that intended to be maintained by upstream? Or is it reserved for the packager? If the Ganglia community releases a tarball called, 3.3.3-2.tar.gz, for example, then someone building RPM packages might release 3.3.3-2-1 The next day, the packager decides to modify a file location within his spec file. He is still using the same upstream tarball. He bumps his release number to 2, so it is 3.3.3-2-2.rpm In this case, the release number is used to distinguish different versions of a spec file maintained outside Ganglia. The same type of thing happens with Debian - the Debian maintainers keep their own artefacts in a repository, and they add a suffix to create the version numbers of their packages. One other comment: when I did the MSI packages (with WiX), I discovered the nasty world of Windows packaging, where you can only have a 4 byte version number, basically like an IP address, written as A.B.C.D where each value is between 0-255. Does anyone still build MSI packages? ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
