For various reasons, Calcite is running in an "agile" mode: time-based releases, not feature-based releases. We don't tend to plan releases or commit to delivering particular sets of features on particular dates. Instead we commit to keeping the code stable, making regular releases (approximately monthly), and to accepting (or at least considering) contributions in a timely manner. If a particular party needs feature X in a release by a particular date, they can achieve it by contributing it in time for that month's release.
However, what you describe would work for projects with a more defined release roadmap. Julian > On Jan 29, 2015, at 2:49 PM, Ted Dunning <[email protected]> wrote: > > On Thu, Jan 29, 2015 at 2:24 PM, Julian Hyde <[email protected]> wrote: > >> Release numbers have a habit of changing just before a release, sometimes >> we do a "quick" intermediate release, leaving some of the goals to the next >> release > > > JIRA actually does batch operations like this really well. > > Using a real release number is very nice because JIRA understands default > ordering well. This makes the dashboards in JIRA very useful as you > schedule issues to put in different releases. > > > Having a next-release version in JIRA can work, but what I would recommend > is that periodically, you pull all such JIRA's and triage them into an > actual version number. If you need an emergency release, you can pull > everything from a particular version number and batch move selected JIRA's > all at once to the emergency patch.
