[Ganglia-developers] releasing 3.3.2 today?
I've updated the document at https://github.com/ganglia/monitor-core/wiki/BuildingARelease and been able to follow the steps there to build a working tarball (at least the tarball works for me). The main change is that it now relies on `make dist' rather than scripts/package-ganglia-release to decide what belongs in the tarball. Does anyone want to sneak in any last minute changes before I tag 3.3.2 and make the tarball available for testing? Where should I put the tarball for people to test before general release? -- 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
Re: [Ganglia-developers] releasing 3.3.2 today?
On 20/03/2012 12:09, Daniel Pocock wrote: I've updated the document at https://github.com/ganglia/monitor-core/wiki/BuildingARelease and been able to follow the steps there to build a working tarball (at least the tarball works for me). The main change is that it now relies on `make dist' rather than scripts/package-ganglia-release to decide what belongs in the tarball. Does anyone want to sneak in any last minute changes before I tag 3.3.2 and make the tarball available for testing? Where should I put the tarball for people to test before general release? I've put a pre-release tarball here: https://sourceforge.net/projects/ganglia/files/pre-release/ It is based on commit e59f87da325bf66d128b086054656ec280b200e2 which has not yet been tagged If there are no loud objections, I'll tag it later today The SHA-256 checksum for this tarball is: 10c587b2f913c47b1ed06e7d00c33192604fe4bf2b3ad113d67abf178b241972 -- 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
Re: [Ganglia-developers] releasing 3.3.2 today?
I tested the tarball and it still does not contain the following files: ganglia-3.3.2/ChangeLog ganglia-3.3.2/libmetrics/ChangeLog ganglia-3.3.2/libmetrics/INSTALL Those files are necessary if you do a autoreconf -fi which is necessary if you add something to any *.am file in the source tree. I build all the additional gmond modules for AIX and Linux on Power this way. Therefore, I have in the respective spec-file a statement like this in %prep: %prep %setup -q # autoreconf seems to need this one touch ChangeLog libmetrics/ChangeLog libmetrics/INSTALL I have verified this and get the exact same behavior on all platforms that I use which include: AIX 5.1, AIX 5.3, SLES9, SLES10, SLES11, RHEL4, RHEL6 So I assume this is nothing specific to AIX but a general issue. Ganglia version 3.3.1 was the first one where this is required, any previous version did not requires this. Before you release version 3.3.2 could you please add (dummy) files for those? Regards, Michael On 03/20/2012 03:07 PM, Daniel Pocock wrote: On 20/03/2012 12:09, Daniel Pocock wrote: I've updated the document at https://github.com/ganglia/monitor-core/wiki/BuildingARelease and been able to follow the steps there to build a working tarball (at least the tarball works for me). The main change is that it now relies on `make dist' rather than scripts/package-ganglia-release to decide what belongs in the tarball. Does anyone want to sneak in any last minute changes before I tag 3.3.2 and make the tarball available for testing? Where should I put the tarball for people to test before general release? I've put a pre-release tarball here: https://sourceforge.net/projects/ganglia/files/pre-release/ It is based on commit e59f87da325bf66d128b086054656ec280b200e2 which has not yet been tagged If there are no loud objections, I'll tag it later today The SHA-256 checksum for this tarball is: 10c587b2f913c47b1ed06e7d00c33192604fe4bf2b3ad113d67abf178b241972 -- 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 -- 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
Re: [Ganglia-developers] releasing 3.3.2 today?
Besides the autoreconf issue I mentioned in my previous email, the tarball compiles cleanly on AIX5.1, AIX5.3, RHEL4, RHEL6, SLES9, SLES10, SLES11 Regards, Michael On 03/20/2012 03:07 PM, Daniel Pocock wrote: On 20/03/2012 12:09, Daniel Pocock wrote: I've updated the document at https://github.com/ganglia/monitor-core/wiki/BuildingARelease and been able to follow the steps there to build a working tarball (at least the tarball works for me). The main change is that it now relies on `make dist' rather than scripts/package-ganglia-release to decide what belongs in the tarball. Does anyone want to sneak in any last minute changes before I tag 3.3.2 and make the tarball available for testing? Where should I put the tarball for people to test before general release? I've put a pre-release tarball here: https://sourceforge.net/projects/ganglia/files/pre-release/ It is based on commit e59f87da325bf66d128b086054656ec280b200e2 which has not yet been tagged If there are no loud objections, I'll tag it later today The SHA-256 checksum for this tarball is: 10c587b2f913c47b1ed06e7d00c33192604fe4bf2b3ad113d67abf178b241972 -- 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 -- 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
Re: [Ganglia-developers] releasing 3.3.2 today?
Hi Daniel: If you let me know where you put the tarballs I will put them in http://ganglia.info/downloads/testing. Cheers, Bernard On Tuesday, March 20, 2012, Daniel Pocock dan...@pocock.com.au wrote: I've updated the document at https://github.com/ganglia/monitor-core/wiki/BuildingARelease and been able to follow the steps there to build a working tarball (at least the tarball works for me). The main change is that it now relies on `make dist' rather than scripts/package-ganglia-release to decide what belongs in the tarball. Does anyone want to sneak in any last minute changes before I tag 3.3.2 and make the tarball available for testing? Where should I put the tarball for people to test before general release? -- 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 -- 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
Re: [Ganglia-developers] releasing 3.3.2 today?
On Tue, Mar 20, 2012 at 12:09:29PM +, Daniel Pocock wrote: Does anyone want to sneak in any last minute changes before I tag 3.3.2 and make the tarball available for testing? there is already a published tag named 3.3.2, if you are not going to release that then it will be better if we skip that release number and aim for 3.3.3 would recommend for testing you do tag it like 3.3.2pre1 or something like that as well. Carlo -- 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
Re: [Ganglia-developers] releasing 3.3.2 today?
Thanks for the prompt feedback I understand from your email that you are not worried if those files are empty? Maintaining extra copies of these files for libmetrics may be another reason to try and avoid the nested configure script On 20/03/2012 15:07, Michael Perzl wrote: I tested the tarball and it still does not contain the following files: ganglia-3.3.2/ChangeLog ganglia-3.3.2/libmetrics/ChangeLog ganglia-3.3.2/libmetrics/INSTALL Those files are necessary if you do a autoreconf -fi which is necessary if you add something to any *.am file in the source tree. I build all the additional gmond modules for AIX and Linux on Power this way. Therefore, I have in the respective spec-file a statement like this in %prep: %prep %setup -q # autoreconf seems to need this one touch ChangeLog libmetrics/ChangeLog libmetrics/INSTALL I have verified this and get the exact same behavior on all platforms that I use which include: AIX 5.1, AIX 5.3, SLES9, SLES10, SLES11, RHEL4, RHEL6 So I assume this is nothing specific to AIX but a general issue. Ganglia version 3.3.1 was the first one where this is required, any previous version did not requires this. Before you release version 3.3.2 could you please add (dummy) files for those? Regards, Michael On 03/20/2012 03:07 PM, Daniel Pocock wrote: On 20/03/2012 12:09, Daniel Pocock wrote: I've updated the document at https://github.com/ganglia/monitor-core/wiki/BuildingARelease and been able to follow the steps there to build a working tarball (at least the tarball works for me). The main change is that it now relies on `make dist' rather than scripts/package-ganglia-release to decide what belongs in the tarball. Does anyone want to sneak in any last minute changes before I tag 3.3.2 and make the tarball available for testing? Where should I put the tarball for people to test before general release? I've put a pre-release tarball here: https://sourceforge.net/projects/ganglia/files/pre-release/ It is based on commit e59f87da325bf66d128b086054656ec280b200e2 which has not yet been tagged If there are no loud objections, I'll tag it later today The SHA-256 checksum for this tarball is: 10c587b2f913c47b1ed06e7d00c33192604fe4bf2b3ad113d67abf178b241972 -- 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 -- 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 -- 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
Re: [Ganglia-developers] releasing 3.3.2 today?
On 20/03/2012 16:32, Carlo Marcelo Arenas Belon wrote: On Tue, Mar 20, 2012 at 12:09:29PM +, Daniel Pocock wrote: Does anyone want to sneak in any last minute changes before I tag 3.3.2 and make the tarball available for testing? there is already a published tag named 3.3.2, if you are not going to release that then it will be better if we skip that release number and aim for 3.3.3 I can see that 3.3.2 exists and there are changes since that tag too, so it is not a good one to release. We will not make a real 3.3.2 release then. 3.3.3 is the new 3.3.2 would recommend for testing you do tag it like 3.3.2pre1 or something like that as well. I agree with that approach, with a slight variation - I'll tag it as 3.3.3dp1 (after adding the ChangeLog file) I will tag the same commit as 3.3.3 if it passes QA (two tags can point to the same commit in the world of git) -- 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
Re: [Ganglia-developers] releasing 3.3.2 today?
On Tue, Mar 20, 2012 at 10:03 AM, Daniel Pocock dan...@pocock.com.au wrote: I agree with that approach, with a slight variation - I'll tag it as 3.3.3dp1 (after adding the ChangeLog file) Quick question -- does this prevent RPM upgrading? i.e. 3.3.3dp1 - 3.3.3? Cheers, Bernard -- 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
Re: [Ganglia-developers] releasing 3.3.2 today?
On 20/03/2012 17:34, Bernard Li wrote: On Tue, Mar 20, 2012 at 10:03 AM, Daniel Pocockdan...@pocock.com.au wrote: I agree with that approach, with a slight variation - I'll tag it as 3.3.3dp1 (after adding the ChangeLog file) Quick question -- does this prevent RPM upgrading? i.e. 3.3.3dp1 - 3.3.3? It is just a tag to help us keep track of what we test, it is not intended for versioning a binary package However, if we want to be able to version binary packages using release candidates, we may need to look at the problem more closely -- 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
Re: [Ganglia-developers] releasing 3.3.2 today?
On Tue, Mar 20, 2012 at 05:36:56PM +, Daniel Pocock wrote: On 20/03/2012 17:34, Bernard Li wrote: On Tue, Mar 20, 2012 at 10:03 AM, Daniel Pocockdan...@pocock.com.au wrote: I agree with that approach, with a slight variation - I'll tag it as 3.3.3dp1 (after adding the ChangeLog file) Quick question -- does this prevent RPM upgrading? i.e. 3.3.3dp1 - 3.3.3? It is just a tag to help us keep track of what we test, it is not intended for versioning a binary package AFAIK the version of this release will be 3.3.2 since micro numbers no longer exist. Carlo -- 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
Re: [Ganglia-developers] releasing 3.3.2 today?
On Tue, Mar 20, 2012 at 13:36, Daniel Pocock dan...@pocock.com.au wrote: On 20/03/2012 17:34, Bernard Li wrote: On Tue, Mar 20, 2012 at 10:03 AM, Daniel Pocockdan...@pocock.com.au wrote: I agree with that approach, with a slight variation - I'll tag it as 3.3.3dp1 (after adding the ChangeLog file) Quick question -- does this prevent RPM upgrading? i.e. 3.3.3dp1 - 3.3.3? It is just a tag to help us keep track of what we test, it is not intended for versioning a binary package However, if we want to be able to version binary packages using release candidates, we may need to look at the problem more closely It matters very much for RPM packages, and I suspect debian packages as well (although I don't know the details of building those). RPMs inherently understand version numbers, and that 3.3.2 is a more recent release than 3.3.1. There are some further syntactic bits added in, such as package release numbers (which are essentially, the least significant digit in the version), but the version number matters a great deal. I think that versions such as 3.3.3pre1, 3.3.3pre2 and 3.3.3 are handled correctly. These pages details the issue: http://fedoraproject.org/wiki/Tools/RPM/VersionComparison http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Version_Tag There are some very ugly was to work around insane versioning schemes, but we don't have that problem (and shouldn't get into hacky workarounds) -- Jesse Becker -- 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
Re: [Ganglia-developers] releasing 3.3.2 today?
On 20/03/2012 17:57, Jesse Becker wrote: On Tue, Mar 20, 2012 at 13:36, Daniel Pocockdan...@pocock.com.au wrote: On 20/03/2012 17:34, Bernard Li wrote: On Tue, Mar 20, 2012 at 10:03 AM, Daniel Pocockdan...@pocock.com.au wrote: I agree with that approach, with a slight variation - I'll tag it as 3.3.3dp1 (after adding the ChangeLog file) Quick question -- does this prevent RPM upgrading? i.e. 3.3.3dp1 - 3.3.3? It is just a tag to help us keep track of what we test, it is not intended for versioning a binary package However, if we want to be able to version binary packages using release candidates, we may need to look at the problem more closely It matters very much for RPM packages, and I suspect debian packages as well (although I don't know the details of building those). RPMs inherently understand version numbers, and that 3.3.2 is a more recent release than 3.3.1. There are some further syntactic bits added in, such as package release numbers (which are essentially, the least significant digit in the version), but the version number matters a great deal. I think that versions such as 3.3.3pre1, 3.3.3pre2 and 3.3.3 are handled correctly. These pages details the issue: http://fedoraproject.org/wiki/Tools/RPM/VersionComparison According to that document, any suffix will make a version appear to be newer than the version without a suffix E.g., if RPM sees both 3.3.3pre1 and 3.3.3, it will believe 3.3.3pre1 is newer Therefore, we would need to have some suffix that we use for the final release too Before deciding on that though, it would be really useful to understand: a) just how much testing do people want to make with release candidates? Are people building RPMs and putting them in yum catalogues, etc, and expecting that to work? b) or is it just sufficient to build a package that can be manually installed (without yum) on a single box as a sanity check? c) and how do we find a common solution for all other platforms (Debian, OpenCSW, etc)? -- 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
Re: [Ganglia-developers] releasing 3.3.2 today?
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. This way, there is a natural way to do upgrades via RPM but the downside is that we might artificially bump up our version numbers by quite a bit for official releases. Anyways, this is just my $0.02. Cheers, Bernard On Tue, Mar 20, 2012 at 11:00 AM, Daniel Pocock dan...@pocock.com.au wrote: On 20/03/2012 17:57, Jesse Becker wrote: On Tue, Mar 20, 2012 at 13:36, Daniel Pocockdan...@pocock.com.au wrote: On 20/03/2012 17:34, Bernard Li wrote: On Tue, Mar 20, 2012 at 10:03 AM, Daniel Pocockdan...@pocock.com.au wrote: I agree with that approach, with a slight variation - I'll tag it as 3.3.3dp1 (after adding the ChangeLog file) Quick question -- does this prevent RPM upgrading? i.e. 3.3.3dp1 - 3.3.3? It is just a tag to help us keep track of what we test, it is not intended for versioning a binary package However, if we want to be able to version binary packages using release candidates, we may need to look at the problem more closely It matters very much for RPM packages, and I suspect debian packages as well (although I don't know the details of building those). RPMs inherently understand version numbers, and that 3.3.2 is a more recent release than 3.3.1. There are some further syntactic bits added in, such as package release numbers (which are essentially, the least significant digit in the version), but the version number matters a great deal. I think that versions such as 3.3.3pre1, 3.3.3pre2 and 3.3.3 are handled correctly. These pages details the issue: http://fedoraproject.org/wiki/Tools/RPM/VersionComparison According to that document, any suffix will make a version appear to be newer than the version without a suffix E.g., if RPM sees both 3.3.3pre1 and 3.3.3, it will believe 3.3.3pre1 is newer Therefore, we would need to have some suffix that we use for the final release too Before deciding on that though, it would be really useful to understand: a) just how much testing do people want to make with release candidates? Are people building RPMs and putting them in yum catalogues, etc, and expecting that to work? b) or is it just sufficient to build a package that can be manually installed (without yum) on a single box as a sanity check? c) and how do we find a common solution for all other platforms (Debian, OpenCSW, etc)? -- 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
Re: [Ganglia-developers] releasing 3.3.2 today?
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
Re: [Ganglia-developers] releasing 3.3.2 today?
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 X.Y.Z, the RPM release could go through several changes with it's own release number. The first RPM-release for a new upstream is 1, and each change increments. So the first official binary release would be something like X.Y.Z.-1, then -2, -3, etc. When Ganglia X.Y.(Z+1) is released, the RPM starts over: X.Y.(Z+1)-1 (and not, say, X.Y.(Z+1)-4) If we do make a policy of tagging pre-releases for testing, i suggest that the tag include something obvious, such as a pre1 sort of suffix. -- Jesse Becker -- 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
Re: [Ganglia-developers] releasing 3.3.2 today?
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
Re: [Ganglia-developers] releasing 3.3.2 today?
On Tue, Mar 20, 2012 at 15:08, Daniel Pocock dan...@pocock.com.au wrote:
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?
Yeah, the nomenclature gets confusing here. :-)
Is that intended to be maintained by upstream?
Or is it reserved for the packager?
The RPM version tag is maintained by upstream. Only in rare cases
should an outside packager assign a version number. And when they
do, IMO, it should be strictly date based--such as 20120320--instead
of an arbitrary version 1.0.
The RPM release, on the other hand, is strictly the purvue of the
packager, and indicates changes to the package that is distributed.
This can included updated metadata for the package, a fix to the build
or install process used in creating the package, fixing permissions,
or even adding code patches to the pristine upstream source code. All
of those are legitimate.
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
If the Ganglia project really did release 3.3.3-2.tar.gz, we should
have our heads examined. :)
But yes, the resulting RPM could potentiall appear as you described,
and it would be a mess.
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
Yep.
In this case, the release number is used to distinguish different
versions of a spec file maintained outside Ganglia.
That's exactly right.
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.
We maintain an RPM repository at $day_job of program that come from
various researchers--many of whom wouldn't know proper software
engineering processes if they were hit over the head with a printed
copy of the of the CMM. Suffice it to say that we have a lot of
interesting version and number schemes to deal with. :-/
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?
Does anyone care? :)
The most complicated, non-contrived version/releases I've see are in
the kernel RPM packages. Here are some examples from a production
Centos 5 host. First, the full package is shown, including the name,
version, release and arch of the package:
$ rpm -q kernel
kernel-2.6.18-194.32.1.el5.centos.plus.x86_64
kernel-2.6.18-238.9.1.el5.centos.plus.x86_64
Now, just showing the version and release:
$ rpm -q --qf %{version} %{release}\n kernel
2.6.18 194.32.1.el5.centos.plus
2.6.18 238.9.1.el5.centos.plus
This works correctly because of the leading numbers in the release
tag--even though there is a bunch of extra non-numeric content as
well.
--
Jesse Becker
--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
Re: [Ganglia-developers] releasing 3.3.2 today?
On 03/20/2012 08:23 PM, Jesse Becker wrote:
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
If the Ganglia project really did release 3.3.3-2.tar.gz, we should
have our heads examined. :)
But yes, the resulting RPM could potentiall appear as you described,
and it would be a mess.
Yes absolutely. Judging from my own experience having built thousands of
RPMs every time any release number that incorporates non-numbers just
leads to more or less confusion. Thus for a released tarball I would
definitely stay away from non-numbers and just stick with something like
X.Y.Z (X,Y,Z in [0..9]*). And just let the package maintainers (Debian,
RHEL etc.) maintain the X.Y.Z-R release number (R) for their package.
The most complicated, non-contrived version/releases I've see are in
the kernel RPM packages. Here are some examples from a production
Centos 5 host. First, the full package is shown, including the name,
version, release and arch of the package:
$ rpm -q kernel
kernel-2.6.18-194.32.1.el5.centos.plus.x86_64
kernel-2.6.18-238.9.1.el5.centos.plus.x86_64
Now, just showing the version and release:
$ rpm -q --qf %{version} %{release}\n kernel
2.6.18 194.32.1.el5.centos.plus
2.6.18 238.9.1.el5.centos.plus
This works correctly because of the leading numbers in the release
tag--even though there is a bunch of extra non-numeric content as
well.
That is because you really can't put any distro-specific version schemes
in the RPM %{version} number but in %{release}. That's why RHEL,
Mandrake etc. define a %{dist} that is typically added to %{release}.
And thankfully we have not run into %{epoch} here which makes things
even more complicated. :-)
Regards,
Michael
--
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
