I wasn't trying to shove last minute changes into the release, just asked a technical question. I didn't realize we already have a branch for 3.2, I thought we were going to only tag 3.2.0. But maybe branching is not a bad idea - we branch before a release, fix an RC issues on the branch and then release from there.
Shai On Mon, May 30, 2011 at 10:52 PM, Robert Muir <rcm...@gmail.com> wrote: > On Mon, May 30, 2011 at 5:15 AM, Shai Erera <ser...@gmail.com> wrote: > > +1. I did not find any issues besides those Mark and Robert reported. > > > > If you respin, will it be done from the latest 3x revision? If so, it > means > > a couple more issues will be released as well, in which case we need to > > ensure their Fix Version is still 3.2. Also, there are issues that are > > marked 3.2 while they were closed after the RC (like LUCENE-3147) - > should > > we change their version to 3.3? Can we easily tell those issues? > > As much as I love LUCENE-3147, I'm not sure if we should try to shove > code changes that aren't blockers into 3.2... it seems at a technical > level there aren't huge problems, but we (Mark, you, Doron, etc) have > found a number of packaging/documentation/configuration files issues > that we might want to address. > > Here is my proposal: let's open a JIRA issue for each thing that was > found, and we decide which are blockers and we backport those to the > branch. The rest we should try to fix in 3.3 > > In all cases it would be good to see if we can "fix" the problem in > some way so that it doesn't pop up in a future release... for example > the solrconfig.xml version was not bumped, we could at a minimum add > it to the wiki page so it isn't forgotten again rather than just > fixing it. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
