[spambayes-dev] More CVS branch/tags questions

[Tony Meyer]

[Mark]
> 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.

I'm pretty sure that you'll find that the branch contains *nothing* that the
trunk doesn't already, apart from the WHAT_IS_NEW.TXT file.  In fact, I'll
bet you 50% of your SpamBayes Outlook plug-in profits to date that that's
the case <wink>.

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

Well, yes.  My only worry is that the trunk contains various code that the
branch doesn't which is definitely not bug-fix and does change sb_server.py,
UserInterface.py and ProxyUI.py a fair bit.  Of course, if I did it right, I
didn't introduce any bugs adding that code anyway, but ...

OTOH, it would be nice to have some of those features in a release sooner
than May 04 :)  (Especially the one that lets people submit a decent bug
report).

I'll upgrade to +0 :)  I think everyone else is in favour, anyway.

> OK - this is my strawman plan:
[...]
> 3) Put together a binary from my current py2exe setup script, 
> which includes CVS and a number of sb_ programs.

Does one need a special version of py2exe for this?  If so, is it one that
there's a binary available for?  (i.e. can I do this without VC++?)

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

And on the 'encourage people to try it out' side, there are a few bugs that
have been fixed since 1.0a7, so they may wish to get those benefits.

[...rest of steps...]

All this looks +1 to me.

> As far as I can tell, almost everyone is in bug-fix-only mode 
> already (except that damn bass-playing Warsaw <wink>).

I kinda am, but certainly wasn't for a period after we went into 'feature
freeze' (hence the new features in the trunk, and not in the branch).  I
would be willing to hold off adding any new features for the (NZ/Au) summer,
although I would like to integrate the Japanese/Asian languages patches
(which have been patiently waiting, and continually updated, for a while
now).  I don't know if that's bug or feature tampering <wink>.

It would be interesting to try and put together a testing framework that
works with the apps (as in the other thread), too, but that could easily be
on a branch.

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

I would be happy doing this, though.  Instead of a branch per feature, what
about a branch per app?  (So (as needed), a sb_server_experimental branch,
an sb_imapfilter_experimental branch, and so on (with better names)).

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

Agreed.

> 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!)

Agreed.

> Moving fast towards 1.0 seems in everyone's benefit

Agreed :)

If everyone else agrees with this, we really ought to put a copy of the
above list somewhere, too, so that Barry can be pointed to it later <wink>.
README-DEVEL.TXT, maybe?

=Tony Meyer