[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]
RE: [XaraXtreme-dev] XaraLX-0.5r1292.tar.bz2 rerolled
- From: Alex Bligh <alex@xxxxxxxxxxx>
- Date: Wed, 14 Jun 2006 23:59:51 +0100
- Subject: RE: [XaraXtreme-dev] XaraLX-0.5r1292.tar.bz2 rerolled
This only affects the 'latest' binary tar archive and 'latest'
autopackage builds. The source packages, and all recommended releases of
the binary, shouldn't change.
I don't want to seem obstreperous, but the 0.5 release cycle showed
exactly the opposite was true. The release tgz got modified twice (IIRC),
I can't remember the cause of one of the mods, but the other was that the
AMD64 & PPC builds of gdraw had not been correctly added. In both case
the numbered build .tgz did not accurately reflect the svnversion. I'm
not trying to criticize how we do things here, because I know it's difficult
to get releases right especially without doing a release fork, but for
external people if we are going to have any long term hope of reliable
debugging, we really must either
a) Be able to get back from a single svnversion to a canonical binary
(this implies not changing ANYTHING on the build server outside
an svn revision); or
b) Be able to identify a release build in some way not only by svnrevision
but by whatever else has changed (that was my "put the build date in"
The more I think about it, the more I think (a) is the right option.
I really don't think we should be publishing binaries that are not
uniquely identifiable by an svnversion. I'm going to go out on a limb
here and suggest we should not be fiddling with stuff directly on the
build server (or at least not on the numbered builds). The build server
should do what it says on the tin - build a given svn versioned release.