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