RE: [XaraXtreme-dev] XaraLX-0.5r1292.tar.bz2 rerolled

["Neil Howe" <NeilH@xxxxxxxx>]

> > 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. 

What I meant was that we don't routinely change the source packages or
the recommended releases of the binary packages, in the way that I've
described can happen with the 'latest' binary packages (due to multiple
builds of the same svn number). 

At the time of the 0.5 release it's true that we did manually adjust the
source archive to add in the CDraw libraries that had been missed (to
avoid a fork or a lot of retesting that would have been required if we'd
had to update the binaries again). There was no second change to any of
the release archives that I can recall. 

>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"
>    option).
> 
> 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.

Ok, so to achieve (a) I guess we have to:-

- Increment the svn revision number each time we make a change to the
build server itself (eg. when we update wx or gcc). Perhaps by checking
in a file that is an audit trail of changes made to the build server?

- After a successful build, we don't build again until the revision
number changes.

Is that the best way forward?

Thanks

Neil