Re: Reminder: impending GNOME 1.4 RC1 deadline



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.

> Never ever release differents contents with the same version number,
> please.


Absolutely. As soon as a tarball is available for public download, it
must never change. Some users will get the first one, some will get the
next, and no one will know if theirs is the most current in a week. If
the version number is incremented when the new tarball goes up, it is
very easy to tell which is newer.

Don't think that people haven't downloaded a tarball if you haven't
announced it! If it is on gnome.org, it will probably be in Debian
within a day. Regardless of whether it is completely broken. Even if it
hasn't been announced, even if the tarball has only been up for five
minutes, a new tarball *must* have a different version.

This may seem like common sense, but the fact is that maintainers of
gnome-related projects violate this on a fairly regular basis.

Note: I'm not ranting at you, Karl. We seem to be in agreement.

Peter

_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]