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
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 ------------------------------------------------------------------------------ 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
