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
_______________________________________________
Ganglia-developers mailing list
Ganglia-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
