Re: [Monotone-devel] monotone 0.48 released

[Stephen Leake]

Thomas Keller <address@hidden> writes:

>> t:monotone-0.48 doesn't build on win32 because of compilation error.
>> Error is trivial (patch attached) and Windows version of monotone-0.48
>> will not exactly match revision tagged as monotone-0.48.
>> 
>> (anyone who made this change in win32/parse_date.cc ... if you don't
>> have win32 build env in under your hand please ping me even using
>> private e-mail and i can recheck build before release, unfortunately i
>> can't supply mingw32 buildbot).
>
> Uh, wow, this comes totally unexpected. Stephe worked together with
> Derek in this area, Stephe, can you confirm that this is / was a
> problem? I'll probably release a 0.48.1 for that if this can be
> confirmed - unfortunately I don't have a Win box around here.

It is a problem, and I did notice it over the weekend. But I was
focussed on the nvm.options branch, and forgot that this would be a
problem for the release.

It's actually due to a cleanup of base.hh stuff, not directly related to
the parse_date.cc work. This was fixed in unix/parse_date.cc last week:

$ mtn annotate unix/parse_date.cc
          ff193643.. by derek 2010-06-06: #include "sanity.hh"

The win32/parse_date.cc patch is in main:

$ mtn annotate win32/parse_date.cc
          be98c1aa.. by zbigg 2010-06-14: #include "sanity.hh"


Without a complete set of buildbots, perhaps we need a more formal poll
of build targets for each release.

Personally, I would much rather respond to such polls than maintain a
buildbot (I did maintain a buildbot for a while; it was a pain).

Another reason to create a release branch for 0.99 and later releases;
main can move on while the polling happens.

Actually, I think we need a release branch now, to commit this change.
Main has moved on from the release point. 

I have not verified that the recent changes in monotone.iss that zbigg
made work on my machine, but I think it's enough that they work on his.

For 1.0, we should get more than one person to confirm each target;
there are some variations on each target, and we need to confirm that
INSTALL is up to date.

One way to manage this would be to put release-critical bugs in
Savannah, assigned to the build testers.

-- 
-- Stephe