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 at 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