Damn, funky webmail, sorry about the earlier incomplete message.
Attempt #2:
Steven,
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.
Otis
----- Original Message ----
From: Steven Parkes <[EMAIL PROTECTED]>
To: java-dev@lucene.apache.org
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
manage.
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
svn.
The main issue is reserving trunk for things going into the next X.Y
release.
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
would
probably make sense to use the FV the way you describe (an
indication
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
X.Y.Z
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
