I agree with Mike. The simpler you make it the higher the chances of the plan being followed. I had to re-read the part about un-released versions. Moreover, rigid rules work great when people doing the work can really spend quality time on the project. This means that people working on Solr through/for their work are really the people who could stick to the plan and everyone else will do whatever is possible for that individual at a time. Hadoop is a good example, and with a couple of people working on Solr full-time now, more structured approach might be possible. That said, I'd be careful of not making things too "work-like" (deadlines, committments, etc.) or else you risk losing people who have enough deadlines and other pressures already.
I'm not sure about that experimental vs. stable release suggestion - I think it can be as simple as "treat the trunk as experimental/in development" (which it is!) and only releases are stable. In other words, no need to change anything there IMHO. Otis ----- Original Message ---- > From: Mike Klaas <[EMAIL PROTECTED]> > To: solr-dev@lucene.apache.org > Sent: Monday, September 22, 2008 1:40:59 PM > Subject: Re: Solr 1.3.0 Release Lessons Learned > > > 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
