[Xapian-devel] Branching for 1.1

[Olly Betts]

On Fri, Feb 22, 2008 at 10:48:55AM +0000, Richard Boulton wrote:
> Fair point - but assuming we don't want the replication stuff in 1.0.6, 
> the branch point is either going to have to be at the point before the 
> replication stuff was added to HEAD, or we're going to have to remove 
> the replication stuff from HEAD temporarily to make a release, then 
> branch and add it back.

Yes, we want to branch from a revision just before the replication stuff
started to be committed, and then cherry pick changes since then to
backport.  But that's as true tomorrow as it is today - it doesn't
really argue for branching at any particular time (except perhaps for
branching before making the replication changes, but we didn't).  There
may be a few more changes we want to backport if we branch later, but
then they'd need to be backported anyway.

> I've just come up with another reason for branching now: I've just been 
> working on allowing Xapian::Stem to be subclassed from Python (to allow 
> a custom stemmer to be supplied to the queryparser) - it turns out that 
> Xapian::Stem::operator() isn't virtual, which is needs to be to allow 
> subclassing from Python.  I can't see any way to fix this without an API 
> change, so it needs to wait for the 1.1 series.

Will this actually work?  Subclassing our reference counted classes
doesn't really work in general...

Ideally Xapian::Stem shouldn't be reference counted, but Martin was
highly resistant to my snowball patch to move towards making the
stemming algorithm variables stack based rather than persistent in a
struct between invocations (which would allow Xapian::Stem to just wrap
an enum).

IIRC, his main argument seemed to be for compatibility with a
closed-source snowball compiler he has, so I'm not very sympathetic, but
forking the language doesn't seem ideal.  It's not ideal that we have a
forked snowball compiler, but at least those changes can hopefully be
merged back fairly easily at some point (I don't think any are likely to
be controversial).

I was hoping longer term to be able to teach the snowball code generator
to make these changes automatically, but that seems quite tricky.

> I _could_ make a branch 
> for this change, but I'm already maintaining 3 branches (at least some 
> of which I'm hoping to be able to merge into HEAD before 1.1), and I'd 
> much prefer to make a branch for 1.0.x and maintain that, rather than 
> make a branch for further changes towards 1.1 and maintain that.

I don't see why it needs its own branch - HEAD is essentially already
the 1.1 branch, so changes suitable for 1.1 can go there.

Although assuming this works, I do have a slight concern about all those
new virtual method calls being imposed on every user as
Xapian::Stem::operator() tends to get used rather a lot.  I think this
needs profiling so we can assess the gain vs pain.

Cheers,
    Olly