Another approach is to make all patches first in the release
branch,
then merge them to trunk. Personally I find that to be a pain,
A royal pain, I agree. And very, very possibly a waste of time, since
there may never be a 2.0.1 release.
I think a lot comes down to the thinking around patch releases and I
don't know how the Lucene community has handled this. There are number
of different approaches, all of which have their plusses and minuses.
but it
might be more scalable. It keeps things synchronized between
Jira and
subversion.
This is the part that I like (synchronization) and find valuable. But
the alternative to checking into both branches and flagging as both (or
the bug fix branch only?) is to flag everything as (for example), 2.1
and nothing as 2.0.1 until a decision is made to actually create a
2.0.1.
I guess I figure the process for 2.0.1, if there was a compelling need
for it, would be to review all the changes that have happened since 2.0
was cut. Were I to do this, I'd look at the ones flagged as 2.1 as well
as the 2.0.1, so I don't see that flagging early really buys much.
Flagging something for 2.0.1 now seems of limited value, too. It's a
balance, right, deciding which patches would go in? In particular, not
only is the value of the patch at issue, but also the pain of applying
it. At this point, a lot of stuff has gone into trunk and a bug fix
patch may have dependences on other stuff. I figure one would have to
see a patch as compelling to the degree that the dependences were
difficult to unknotting. And I figure someone flagging something as
2.0.1 now isn't going to spend the time to figure all that stuff out. I
wouldn't, since I don't know if there ever will be a 2.0.1.
On the other hand, I like the idea of being able to look at the list of
resolved issues and see the Fix Version/s to tell me where they've been
checked in. And this ties into Jira's release notes thing. Or even the
change log. If there were a 2.0.1 release and then a 2.1 release, what
would the change log and release notes for 2.1 be relative to? I don't
really like the idea of mucking with the trunk change log when the
(putative) 2.0.1 release is made so that the change log groups things to
show differences between 2.1 and 2.0.1 (instead of 2.1 and 2.0, which is
what it has now). If that's the case, that 2.1 is relative to 2.0, then
no issue should be flagged only a patch release, but a main release and
one or more patch releases.
But that's wrong, too. Sometimes bugs exist on a patch branch that don't
exist on the trunk, which would mean that if Jira FVs is really going to
reflect reality, 2.0.1 can't implicitly imply 2.1, since that might not
always be the case.
Of course, all this can happen at release time, for both patch and main
releases. I don't think the flagging approach (flag only main release
vs. flag only patch release (vs. flag both?)) results in differences in
Fix Version/s on closed issues.
But consistency would help me and I suppose I still favor flagging
everything as 2.1 now. If not for the simple reason that I don't know
how to decide if something should go into some 2.0.1 when I don't know
what's going to trigger the need for it.
I kinda feel like I should apologize for belaboring all this but I got
people that want answers to these questions. I'll right up the wiki
summary.
-----Original Message-----
From: Doug Cutting [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 26, 2006 12:28 PM
To: java-dev@lucene.apache.org
Subject: Re: releases
Chris Hostetter wrote:
> this is the past thread i was thinking about before...
>
>
http://www.archivum.info/java-dev@lucene.apache.org/2006-06/msg00012.htm
l
>
> ...refering to leaving the release branches clean untill just before a
> point release when all the desired changes can get merged in.
That's the way I find it easiest to manage. Otherwise you have to
remember which patches have been applied to the branch and which have
not. So I prefer to merge them to the branch them all-at-once. However
if the branch diverges from trunk much then that's impractical.
> allthough now i'm more confused about how exactly "Fix Version" should
be
> used ... Doug seemed to be advocating one usage in that htread, and a
> differnet usage in the more recent thread.
Fix Version should name the first release that the patch is intended to
appear in. This may or may not correspond directly to the subversion
branch that the patch is committed to.
Another approach is to make all patches first in the release branch,
then merge them to trunk. Personally I find that to be a pain, but it
might be more scalable. It keeps things synchronized between Jira and
subversion.
> it seems like we really need a wiki on how we *want* to use the
various
> fields in Jira (assignee, "New", "Pathc available", "Fix Version",
etc...)
+1
Doug
---------------------------------------------------------------------
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]
