Hi Luc. > > 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 ...
I want to stress that scheduling releases is simple; it is scheduling code development that has proven problematic (cf. Commons Math v2.2). > 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. What I propose has been more clearly explained by Sébastien. We all want to "release often"; so when the "due" (but not promised!) date (say, every 6 months) comes close, we really do our best to clean up the code (and postpone all issues that will need more development time), and release all the work that has been done and agreed on until then. This will greatly alleviate the problem you cite above. > > A fuzzy objective like "at least twice a year" sound a good compromise > to me. If you want to call "twice a year" what I call "every 6 months", that's fine. ;-) Best, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
