: 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
