As opposed to calendar-based release scheduling, I would suggest perhaps using a more feature-based approach. For transparency, use JIRA's target version (or whatever it's called) to schedule which releases will contain fixes for which issues. The reason I'm hesitant to put something on the calendar is because we are a volunteer-based organization (for the most part). What if the developers just don't have time to get to anything? Of course, there's the flip side of that equation. What if our developers rock out everything that should be in a release? Why wait until the end of the 6 month window? Release now! :)
On Tue, Mar 27, 2012 at 1:52 PM, Gilles Sadowski <gil...@harfang.homelinux.org> wrote: > Hi. > >> I am -1 to publishing any sort of release schedule to which we would >> be held accountable. > > I was speaking for Commons Math. IMHO, it is a disservice to the project to > have releases more than 12 months apart, as it has just been the case. > This gives the feeling that the code is stable and in maintenance mode, > which is totally wrong for Commons Math (contrary to most of the projects in > Commons). > Moreover there is no notion of accountability, just a little effort to be > more transparent. Indeed, what I'm asking is a presentation of the criteria > such that this statement is true: > "[...] the component has reached a state where another release is worth > doing [...]" > > > Gilles > > --------------------------------------------------------------------- > 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
