Good questions.

For now, I think a reasonable default process would be to consider any bugs fixed in future releases to be "fixed"/closed in a bug tracker. Then, if enough people continue to complain (by adding to the bug report or submitting new bugs) about the issue in the earlier release, maybe re-open the bug for the earlier release, and then fix it in the earlier release.

Something like that. But by default, at least, I think it would be easiest to consider them "fixed".

A lot of people (including myself) are in favor of maintaining our final/stable releases with additional (critical-only) patches/updates. This needs to be discussed further by some sort of "release" team, but I'd be in favor of starting to do this with the 3.8 release. You could provide this via the regular update stream (which Squeak Central used to do), but also provide bugfix point releases on squeak.org such as 3.8.1, 3.8.2, etc. But you'd still have the same beta cycle that we have now to make sure the first final release (e.g. 3.8) wasn't horribly buggy.

- Doug

-------------------------- On Thu, 24 Feb 2005 11:37:16 -0600, "Ken Causey" ken@kencausey.com said:

I'm among the group that is trying to work on improving the harvesting process. One of the issues that occur to me is how to handle an issue that is no longer an issue in the latest greatest update but is a problem in the last update of a released version.

In other words let's say bug X is verifiable in a fully updated 3.7 image but has been fixed in an update for 3.9. Is this issue 'fixed'? Or does it need to be fixed in 3.7 to be truly fixed?

I realize that to some extent it depends on the issue. But then who decides what needs fixing in a released version and what doesn't?

Also at what point to a release become so old that no bug in that release is worth worrying about?

Ken