I found no mention in the web site's policy manual of version numbering. Since it has made the transition to the policy list, I am advocating reviewing the policy (in the packaging manual) for possible changes to solve future problems caused by the packaging of pre-release upstream versions.
If policy is not created/changed to handle this, we are doomed to revisit it. >From the *packaging manual* on http://www.debian.org/doc/packaging-manuals/packaging.html/ch-versions.html (I found no mention in the policy manual of version numbering.) dpkg imposes an ordering on version numbers, so that it can tell whether packages are being up- or downgraded and so that dselect can tell whether a package it finds available is newer than the one installed on the system. The version number format has the most significant parts (as far as comparison is concerned) at the beginning. [skip epoch and upstream sections] debian-revision This part of the version represents the version of the modifications that were made to the package to make it a Debian binary package. It is in the same format as the upstream-version and dpkg compares it in the same way. It is optional; if it isn't present then the upstream-version may not contain a hyphen. This format represents the case where a piece of software was written specifically to be turned into a Debian binary package, and so there is only one `debianization' of it and therefore no revision indication is required. It is conventional to restart the debian-revision at 1 each time the upstream-version is increased. dpkg will break the upstream-version and debian-revision apart at the last hyphen in the string. The absence of a debian-revision compares earlier than the presence of one (but note that the debian- revision is the least significant part of the version number). The debian-revision may contain only alphanumerics and the characters + and . (plus and full stop). Note there is no mention of non-maintainer releases. Granted the proposal I advocated would violate the current letter of the packaging manual by incrementing the debian version number for non-maintainer releases. If pressed I might claim the software was made into a debian package, then the debian package was changed to include patches prior to a full upstream release. As many have pointed out, epochs could also be used to 'solve' this problem, but I don't agree with that solution for *this* problem (pre-release versions). I think we need a way to uniformly and clearly distinguish pre-release software from release software, and that is what I proposed. Pat (who still has problems telling left from right) > -----Original Message----- > From: Scott K. Ellis [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 25, 1998 3:22 PM > To: Dale Scheetz; [email protected] > Subject: Re: libc6_2.0.7 release notes... > > > On Thu, Jun 25, 1998 at 02:09:43PM -0400, Dale Scheetz wrote: > > On Thu, 25 Jun 1998, Jules Bean wrote: > > > > > Someone suggested this earlier in the discussion, and someone > else pointed > > > out that this is clearly against policy, since anything after > the '-' should > > > reflect debian-specific packaging changes, not upstream changes. > > > > > Then I would argue that the policy statement is self > contradictory. The -0 > > and -1 suffixes create (and declare) those releases to be source change > > releases, which are, obviously, upstream changes. > > That's odd. It was my understanding that a -0 release simply indicated a > non-maintainer release of a new upstream source. I'm not aware > of any place > in the policy manuals that says that -0 and -1 might be different > sources. > I know dpkg-buildpackage considers either one grounds for a source upload, > but I don't see where it is mentioned (or obvious) that they are different > sources. dpkg-buildpackage just can't deduce that there might have been > a -0 release, so it must assume that -1 is the first release. > > I'm still really vague on what REAL technical objection has been raised to > actually using (oh, horror!) epochs. Yes, it will remain in the version > number "forever". So what? Who cares? If the epoch reaches 50, who is > going to notice and care? The reason we use the upstream version > numbers is > for recognition. If they don't fit, we use epochs and be done > with it. The > version numbers are recognisable in the filenames, and dpkg knows which > comes first. I see that as a good thing. > > -- > Scott K. Ellis <[EMAIL PROTECTED]> > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
