Hi, Le 27/03/2012 21:08, Matt Benson a écrit : > I have to agree with James here. However, if the mysterious > team-who-wishes-to-contribute is dead set on 6 month release cycles, > it is certainly within their power to make sure 4.5 months ahead of > time that every open JIRA issue has a patch attached, and to nag the > team incessantly for the following 1.5 months. ;P
I agree too that a fixed schedule would be almost impossible to do. We have already proven we were not good at schedules ... On the other hand, we really need to improve, our current release frequency is clearly much too low. This almost force people to use development version when they are eager to have some bug fix or important feature they need. A fuzzy objective like "at least twice a year" sound a good compromise to me. Luc > > Matt > > On Tue, Mar 27, 2012 at 1:53 PM, James Carman > <ja...@carmanconsulting.com> wrote: >> I don't have a problem saying something like "we will attempt to >> release at least twice per year." I don't think it would be wise to >> say, "we will have a release on 1/1 and 7/1 every year." >> >> Release early! Release often! Have 12 releases a year if you want. >> Just don't promise them. >> >> On Tue, Mar 27, 2012 at 2:49 PM, Sébastien Brisard >> <sebastien.bris...@m4x.org> wrote: >>> Hello, >>> maybe we could mix both approaches. >>> >>> Following James, releases could be feature-based, using the JIRA >>> system. If after 3 months, the goal is reached, we could release. >>> >>> However, as Gilles suggested we could at least do our best to at least >>> try and release twice a year. This means that about a month before the >>> "deadline", we could all review the present state of the library, and >>> decide what should be done to get it released. That's what happened in >>> 3.0: there was an urge for a release, so some feature requests were >>> just postponed, and we all tried to clear up the most urgent JIRA >>> tickets. >>> >>> As for working both on 3.1 and 4.0, I'm all for it (means I'll >>> probably be struggling again with svn, though...). >>> >>> Sébastien >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
