lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <hossman_luc...@fucit.org>
Subject RE: releases
Date Thu, 26 Oct 2006 22:09:47 GMT

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

It's kind of a chicken/egg problem ... either releases are scheduled, and
the Fix Version can be used by the committers to denote to the release
manager(s): "Issue A is a bug fix and adds no new functionality, so it
should go in 2.0.1 when/if it's created.  Issue B is new functionality
that changes no existing APIs so it should wait for 2.1, Issue C
changes existing APIs so it should wait for 3.0" ...and hte release
managers just merge the changes with teh appropriate flag into the lreease
branch.
   ...OR...
release are driven by need, and someone looks at the list of
resolved issues and their flags and either says either "hmmm, looks like
we should make a 2.0.1 release" or "hmm, not a lot of need for a 2.0.1
release, but we seem to have plenty of stuff to warrant a 2.1 release."

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

it's not really about flagging a patch as being 2.0.1 worthy ... it's
indicating that the issue is 2.0.1 worthy ... the "fix" for a 2.0.1
release branch might be completely different from what is done in the
trunk.

: 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

they would be relative 2.0 ... the 2.0.1 additions to the notes wouldn't
be there becuase they would be on the 2.0 release branch.

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

see ... i would argue that it makes more sense to just leave FV
unspecified unless you have a specific reason why you think the issue you
are resolving should *drive* the creation of a release, or be merged into
a specific release branch.  Only if you are saying "this is an urgent bug
fix" should you flag something as 2.0.1 indicating that you think we need
a 2.0.1 release.

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

It's good to hash these issues out ... we do need better documentation so
that people "discovering" Lucene have a way to make sense of both Jira and
the release process/plan



-Hoss


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message