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:20:42 GMT
Damn, funky webmail, sorry about the earlier incomplete message.

Attempt #2:


Regarding your payloads example and 2.1 vs. 3.0, there is a simpler approach, and one that
we have pretty much (unintentionally?) been using.  Larger chunks of work take longer, need
more eyes to check them, to test them locally, iron out bugs, etc. and finally approve and
commit them.  Therefore, while this work is in progress, it's all done via patches in JIRA,
and people's local repositories.  No commits until the solid patch is available.

If the change is sufficiently large and warrants a major release, we can make the release
with whatever is in the trunk, say 2.1, and then commit the big patch in the trunk that's
headed for 3.0 (n.b. hypothetical version - we may have 2.2, 2.3, etc., who knows), avoiding
extra branches.  Lucene is pretty mature and there are typically not that many big changes
being worked on in parallel.

I think this is simpler, easier to manage, less likely to cause a mistake, requires less SVN
merging knowledge, etc.  I think that's what has been practised so far, and I think it has
worked pretty well.  I don't think we are looking for a change here.


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