Watching the various wishes on this thread (release early, release
often; I want feature X included in the release; etc), I'd propose this
for an approach that I believe could cover all bases:
* Anyone can propose a release
* They should give n days warning (suggest 1 wk)
* Ideally, a code freeze happens after n/2 days:
* an RC is created at this point, to aid testing
* only bugs/regressions found in RC will be committed
* if others want to continue coding, a release branch can be
created
* if anyone commits code between 0 and n/2 days, they also commit to
fixing reported bugs between n/2 and n days
* Proposer can then roll the release and call for a vote when n days
are up, assuming they are happy that all reported bugs are resolved
Getting a little more formal, we could have suggested approximate dates
on calendar, and folks could volunteer to take on those releases,
following the above process.
This would give folks warning to get code in that is 'nearly' finished,
yet prevent the release waiting on 'nearly finished' code. It would also
put most of the power to make the release into the hands of the release
manager.
Thoughts?
Upayavira
On Sat, 28 May 2011 17:09 -0400, "Grant Ingersoll" <gsing...@apache.org>
wrote:
> I think I kicked off the 3.2 release discussion back a bit saying it's
> been about 3 mos (come June). To me, roughly every 3 months or so is
> ideal.
>
> I'm thinking about setting up a Google calendar that we can put reminders
> on (as well as other Lucene related events) and then share it publicly
> (committers would have write access)
>
>
> On May 28, 2011, at 9:49 AM, Mark Miller wrote:
>
> > The cost of the overhead is paid by volunteers - there is no *need* to
> > release every month. But if someone is so concerned that a few features
> > have not made it in this release that are important - there is no reason
> > not too as well - given that the person is willing to roll the release.
> >
> > Releases take 3 +1s - I'll give my +1 as often as someone puts artifacts in
> > front of me and I have time to verify them.
> >
> > The worry of releasing TOO much is so premature it's not even funny :)
> >
> > Sent from my iPad
> >
> > On May 28, 2011, at 1:25 AM, "David Smiley (@MITRE.org)"
> > <dsmi...@mitre.org> wrote:
> >
> >> Clearly a year+ is too long to release, and thankfully it appears that's in
> >> the past for Lucene/Solr. But on the other extreme, one can release too
> >> quickly as well, of course. There is overhead to performing the release
> >> itself. Consequently there should be enough "goodness" in the release to
> >> make it feel worthwhile. And because we value stability and robustness in
> >> Lucene/Solr, changed code should have *some* amount of time to be
> >> potentially used and tested further. And there's impact on the user
> >> community. If a release occurred too frequently then there might be very
> >> little meaningful improvements in the release. I believe it is Hudson (now
> >> Jenkins) that followed that extreme of I think releasing every week or so.
> >> It's so frequent that as an admin of such a server where I work, I don't
> >> even care to look at what's new in the releases because there are too many
> >> of them--I've become apathetic when I was initially excited to use it. So
> >> hopefully with each release there's something truly cool to tell others
> >> about in Lucene/Solr.
> >>
> >> Gauging these factors is of course very subjective. Personally, I think 3
> >> months is just right, 1 or less is too fast. Given that v3.1 was released 2
> >> months ago and there are some truly cool features like Result Grouping in
> >> Solr to announce in 3.2. I'm in favor of a release.
> >>
> >> ~ David Smiley
> >>
> >> -----
> >> Author: https://www.packtpub.com/solr-1-4-enterprise-search-server/book
> >> --
> >> View this message in context:
> >> http://lucene.472066.n3.nabble.com/VOTE-Release-Lucene-Solr-3-2-0-tp2993434p2995419.html
> >> Sent from the Lucene - Java Developer mailing list archive at Nabble.com.
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >> For additional commands, e-mail: dev-h...@lucene.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>
> --------------------------
> Grant Ingersoll
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
---
Enterprise Search Consultant at Sourcesense UK,
Making Sense of Open Source
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
