lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Otis Gospodnetic <>
Subject Re: releases
Date Fri, 27 Oct 2006 23:12:39 GMT

----- Original Message ----
From: Steven Parkes <>
Sent: Friday, October 27, 2006 4:45:16 PM
Subject: RE: releases

    not neccessarily ... if somethings in the trunk, you're saying
it should
    be included in a release eventually ... but that doesn't
neccessarily need
    ot be the 2.1 release ,it might be the 3.0 release

I can see this in theory, but do our use patterns for svn support it? My
understanding is that trunk is the proto-X.Y.0 branch. If you start
checking X.Y+1.0 or X+1.0.0 stuff in there, it's going to make creating
an X.Y.0 release difficult, right? It's possible to imagine yanking the
stuff out, but the release process just got a lot more difficult to

The svn model Lucene is using, as I understand it, is one main branch
(trunk) for development plus patch branches for cut releases (in case
patch release are ever deemed necessary). Only trunk is "actively"
maintained: it's the only thing that gets most commits. The patch
branches aren't actively maintained: things aren't pushed/committed to
them routinely. Instead, if a patch release is deemed critical, patches
are pulled/ported from trunk, facilitated by Jira and svn merge.

This makes life a lot easier. Having two branches getting "lots" of
changes is difficult to manage. I've not had to do it. And as far as I
know, Lucene has been able to function well w/o that complexity.

Will the Lucene needs ever result in a need for a more complex svn use
model? I guess a straw man example would be a 3.0 release. Say we wanted
to start working on payloads, since that's been talked about as
something big enough for people to be cautious of. How would that work
in svn? You don't want to check that into trunk today would you, if
trunk were to be planned for use of a 2.1 or 2.X?

One could start a 3.0 branch along side trunk or a 2.X branch, but
having two branches that are going to create non-patch releases is
painful, isn't it? Having to commit/test code twice? You'd presumably
want the 3.0 branch to get everything that went into any 2.X branch.

Because of the complexity, most projects I'm aware of don't want to deal
with two non-patch branches if they can at all possibly avoid it.

I'm aware of a couple of alternatives. One is to create a "payloads"
branch. It gets only the payloads work. When it's decided that work on
3.0 can commence on trunk, payloads (and anything else being withheld
for a major X.0.0 release) can get merged in.

Alternatively, you can do this work in contrib or just with patches in

The main issue is reserving trunk for things going into the next X.Y

Is that the way Lucene has operated?

    i think what you are describing is really waht the intended
purpose of FV
    is ...

I did look at the Jira docs and they seem ambiguous. Can either mean
planned or completed.

One reason that one might want to reserve FV for committed code is that
it's used by the Release Notes feature. Of course, I suppose it depends
on whether one cares about that feature or if one wants it to represent
what might go in, but for me, I like the idea that it's a summary of
what's committed on the current branch. When people ask me now what's
going to be in a putative 2.1, I'd like to be able to push the Release
Notes button and say that's what's in so far. But I can't, given the way
we use FV now. Of course, that will only work if FV is used consistently
and all (significant?) work committed in svn is reflected in Jira.

    if we really want to track all of this infomation better, it
    probably make sense to use the FV the way you describe (an
    as to what release new functionality / bug-fixes have been
    commited to) and have new (optional) fields indicating what FV
has been
    used for in the past:
      How significant is are the changes resulting from this issue?
        A - major bug fix; no api changes; should be put into an
            releases ASAP
        B - minor bug fix or new functionality; only backwards
compatible api
            changes, should be included in the next X.Y.0 release
        C - major functionality change; significant API changes,
requires a
            new X.0 release.

Hmmm ... this is starting to sound familiar. Is A the same thing as
Critical/Bug and B {Major/Minor/Trivial}/Bug?

Don't know about C. There's also Affects Version/s, so C could be New
Feature/AV/s = 3.0?

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message