[spambayes-dev] More CVS branch/tags questions

[Mark Hammond]

> [Mark]
> > Should we abandon the branch, merging everything
> > back to the trunk?  I don't see the branch is offering
> > us any value, firstly as it is now very old, and secondly
> > as the trunk doesn't seem to have had any changes that
> > truly should be post 1.0 - unless we don't count a
> > Windows binary in 1.0.
>
> The sb_server interface has had quite a few changes on the trunk that
> haven't been put into the branch.  I certainly hope that they didn't
> introduce new bugs (since I wrote most of it), but they may
> have done.  I
> think it would certainly mean that we should do another
> release before we
> consider that things are stable.  OTOH, the changes were all
> sugar, and they
> could be ripped out and added back in another day.
>
> Anyone have any idea how many people are using sb_server from
> cvs?  Enough
> that the changes (they're fairly old now, even though they've
> never made a
> release) seem fairly stable?
>
> -0 from me, anyway.

I should clarify that by "abandon the branch", I don't actually mean abandon
<wink>.  I mean we merge the branch back onto the trunk (cvs up -j ...),
handling any conflicts and resolving the pain it may cause.  I haven't tried
to see what conflicts actually arise, but am willing to.  I expect the only
real conflicts will be where a bug *has* been fixed in both places.

Or is that what you thought I meant, and still -0?

> still thinking of doing one final Outlook only one?  Give me a list of
> things to do <wink>.  (Or maybe you already did; I'll have to
> look through
> the stuff I have on my to-do list).

OK - this is my strawman plan:
1) Merge as above.
2) Let things settle for a week or so, so poor CVS users all get to suffer
alone.
3) Put together a binary from my current py2exe setup script, which includes
CVS and a number of sb_ programs.
4) Announce this binary as a "binary-beta", calling it 0.75 or something.
5) Any major bugs will presumably be part of the "binary framework", so
maybe 0.76 etc, depending on the damage.
6) Move towards release 0.8 - this will be simultaneous windows-binary and
source.
7) Move towards release 0.9 - aim for 4 weeks after 0.8, addressing only
bugs.
8) Just *before* the 0.9 release, cut a new 1.0 branch.  Release 0.9.
9) Move towards 1.0, again aiming for 4 weeks, possibly with 2x release
candidates.

As far as I can tell, almost everyone is in bug-fix-only mode already
(except that damn bass-playing Warsaw <wink>).  I'm pretty much in that mode
for Outlook too.  So up until (8), which is when we cut a new 1.0 branch,
all new real features go one some development branch (a branch per feature -
whatever).  We all reserve our right to use a fairly liberal definition of
"bug" for low-risk, high-benefit tweaks, but I think our app is mature
enough that we can happily tell people who want truly new features to grab a
CVS branch.  After the branch is cut, we get seriously anal about "bugfix
only", with the expectation the branch lasts only 4 weeks (which flies when
everyone is busy!)

This is likely to impact almost no-one once we are re-merged.  Moving fast
towards 1.0 seems in everyones benefit, and this would get us there around
the end of Feb.  If we can get there sooner due to the only bugs being old
ones we don't know how to fix, all the better.

Happy-new-year ly,

Mark.