On 22-Sep-08, at 10:34 AM, Shalin Shekhar Mangar wrote:
I'd like to propose a more pro-active approach to release planning
by the
community. At any given time, let's have two versions in JIRA. Only
those
issues which a committer has assigned to himself should be in the
first
un-released version. All unassigned issues must be kept in the second
un-released version. If a committer assigns and promotes an issue to
the
first un-released version, he should feel confident enough to
resolve the
issue one way or another within 3 months of the last release else he
should
mark it for the second version. At any given time, anybody can call
a vote
on releasing with the trunk features. If we feel confident enough
and the
list of resolved issues substantial enough, we can work according to
our
current way of release planning (deferring open issues, creating a
branch,
prioritizing bugs, putting up an RC and then release).
I think that this is the right approach, but I don't think that it
needs to be that complicated. For issues without the "expectation of
completion" that you mention, it is fine to just not assign a version
to the issue. It _would_ be useful, OTOH, to have a 2.0 version in
JIRA for issues we know won't be resolved back-compatibly.
-Mike
