I think we should shoot for putting out another release in about 2 weeks. We need to release some Windows and Linux binaries anyway, so we might as well do a new release and include the bug fixes since the last one. Also, we should pick a few small features or easily fixed bugs to get done in that time. Since we have an issue tracker now, we should put the goals in there and mark them as priority Critical or High.
Let's just release when the time comes, though, instead of waiting for all of the features to get implemented (if they haven't been) -- those can just wait for the next release cycle.
I agree. Here's what I'm getting at, though. Some issues on the tracker are marked as "Critical". I see this to mean "These must be fixed before next release". For instance, I marked the
SCons install target bug as Critical because we can't really make an autopackage until it's fixed. So that's blocking the next release. Others, for instance
this one, seem like they could possibly wait until next release if they aren't done in time, since that one particularly would be a performance enhancement. Perhaps this one should be marked as "High" which I see as meaning "Would be nice to have in the next release but not blocking a release". So if we don't get that one done before release, it can slide. Make sense?
OK, I moved the ones that I had as critical to VeryHigh.
Works for me!
High: Gee we ought to fix that by next release.
VeryHigh: Damn that's annoying we gotta fix it.
Critical: We can't release til this is fixed.
