Just to follow up on this - There is always a list of 'should be fixed/done before x.y.z release'. The general problem is that tends to be very difficult to ever meet. this is because often times one things leads to another. Doing X then leads that Y should be done sooner, and not later. And there is always the potential/likelihood that someone works on/checks in their pet project, with associated set of bugs. In the past, I've generally just done an intermediate release (1.40, 1.50, etc) when the number of bugs seemed relatively low and there has been enough time since the last major checkins to make sure any bugs have been sorted out from that. Which sort of makes waiting for big commits difficult - doing so will delay any release cycle - you have to wait for the commit to be ready, and then have to wait some amount of time before making an actual release. As for release numbering and features, it could be useful to make a roadmap. However, it then might become the question of do you target for releasing by some data (eg, 2.0 by end of the year or something), or by list of features (2.0 will have ....) _______________________________________________ crossfire-devel mailing list crossfire-devel at lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel