[ANN] bzr 2.4b3 has gone gold

[vila]

>>>>> Gordon Tyler <gordon at doxxx.net> writes:

<snip/>

    >> Of course, Vincent cheated by announcing this 2 hours after
    >> end-of-day time. Thinking he could give the Mac OSX guys a full
    >> day's head start on packaging. Good thing I checked my email in
    >> the evening to see the gauntlet thrown down, pick it up and
    >> respond to the challenge.

Hehe. Well done for the windows installers !


Where I cheated even more is that I won't build the OSX 10.5 installer
because we don't support python2.5 anymore ;-D

I think it's reasonable to keep building the 2.3 series ones as 10.7 is
really close now so we'll have even less 10.5 users.

If  someone wants to invest time into exploring how to build an
installer that can either embed a python 2.6 or requires one to be
installed, see http://pad.lv/776523 and http://pad.lv/776996 

    > Curse you! *shakes fist* Still building... I saw the email earlier
    > but I don't have access to the Mac until I get home from work. :P

    > Uploading now, should be available in a few minutes.

Well done too :)

    >> Running into that revealed the "buildout doesn't actually
    >> re-download newer branches" bugs. It will populate a branch with
    >> the right tag if you don't have anything, but if something is
    >> there, it won't re-download a branch. So we really just have to
    >> nuke build-win32/*/bzr-*/ between releases. And all we really
    >> save is re-downloading some of the Tortoise and SVN libs.

    > It would be nice to have a somewhat generic package dependency
    > resolution tool that knew how to download and unpack tarballs or
    > checkout bzr branches according to some version specification and
    > would automagically do The Right Thing (TM) when those version
    > specifications change compared to what is sitting in the
    > filesystem.

Who's cheating now ? This sounds like something almost done in the OSX
installer toolchain:)

I fully agree with that, having enjoyed the way the OSX installer is
built.

Even if we can't share everything from that as windows is... what it is,
it would be nice to converge to a makefile based approach for that,
relying on these shared tools for the actions (we already requires GNU
make so no need to start chasing other technologies IMHO).

   Vincent