Re: Reminder: impending GNOME 1.4 RC1 deadline
- From: Owen Taylor <otaylor redhat com>
- To: gnome-hackers gnome org
- Subject: Re: Reminder: impending GNOME 1.4 RC1 deadline
- Date: 10 Mar 2001 16:17:52 -0500
Peter Teichman <peter ximian com> writes:
> On 10 Mar 2001 08:15:17 +0100, Karl Eichwalder wrote:
> > Maciej Stachowiak <mjs eazel com> writes:
> >
> > > Since our goal is not to change anything between RC1 and final unless
> > > there are major showstoppers, you should build these packages as if
> > > they are final. That is, set all version numbers to be something GNOME
> > > 1.4 final looking (so no 1.3.x's, no whatever-beta2's, etc).
> >
> > But if it's needed to change anything for the final release you'll have
> > to increase the 1.4 version (1.4.1)!
>
>
> Oh, the horror.
>
> Remember, folks. Version strings are completely arbitrary constructs. It
> doesn't matter to a user whether the package is version 1.4.0 or 1.4.1.
> Having to increase a number due to critical bugs found in the testing
> cycle should be expected. They are critical bugs, and a new version is
> required.
>
> That said, it makes things difficult for people building binary packages
> if the version string contains anything other than dot-separated digits.
> 1.2.9pre1, for example, is thought to be newer than 1.2.9 by every
> packaging system I've ever seen. This requires a packager to introduce a
> package epoch when the final version comes out, munge the version string
> into something the package system would think is older, or ignore the
> prerelease completely.
To repeat, once, once, again.
Yes, package maintainers probably shouldn't call there packages
1.2.9pre1, but if they do, then packagers have to realize
that the right solution is NOT to introduce an epoch, but
for the packager to deal with the problem when creating
the package, by either versioning the package:
1.2.8.91-1
Or by encoding the "pre" status into the release
1.2.8-0.1
(My preferred solution). There is no reason whatsoever that the
name of the tarball needs to be embedded in the package name,
and an Epoch is very much a too heavy-weight solution to this
problem.
Owen
[ Who's going to be very upset if he finds out that the Ximian
folks increased the epoch on their packages for GTK+-1.2.9
after being explicitely told what they needed to do. ]
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]