Re: [development] Re: fixed project releases
21:44 < killes> Dries_: please remove all releases older than 4.5, all non-4.7 RCs
+1
What to do with the issues associated with those releases?
Change the release to 4.5 for all pre-4.5 releases. I assume there will be a comment added to the issue recording the change.
Create a new release called "obsolete" (or some other obnoxious but creative name) and assign anything that is now pre 4.5 to be against it so we know this is old stuff if we need to know, and it does not get in the way later. One related issue: any issue that says "cvs" now and does not get fixed, remains as cvs even if we release 4.7, then 4.8 then 5.0, then 5.1, ...etc. Later someone has to go thru and mark some of them as no longer applicable, ...etc. Is there a better way of doing this? For example, all current issues are marked either "4.6" or "pre-4.7". Future ones become "4.7" if they are against that live branch, or "pre-4.8". Would this ease tracking of old issue and give a sense of how long they have been around (since how many releases, not number of days).
Create a new release called "obsolete" (or some other obnoxious but creative name) and assign anything that is now pre 4.5 to be against it so we know this is old stuff if we need to know, and it does not get in the way later.
works for me. i'd even like to see 4.5 issues put in the obsolete bin. lets clean the house for real.
One related issue: any issue that says "cvs" now and does not get fixed, remains as cvs even if we release 4.7, then 4.8 then 5.0, then 5.1, ...etc. Later someone has to go thru and mark some of them as no longer applicable, ...etc.
Is there a better way of doing this? For example, all current issues are marked either "4.6" or "pre-4.7". Future ones become "4.7" if they are against that live branch, or "pre-4.8".
Would this ease tracking of old issue and give a sense of how long they have been around (since how many releases, not number of days).
It does not work this way. One bug filed against cvs in the 4.5 days could still perfectly be applicable against current days CVS. The fact that a new release is out, does not mean every bug against the prereleease code is now fixed, or should be fixed in that release cycle. Goba
On 1/27/06, Gabor Hojtsy <gabor@hojtsy.hu> wrote:
One related issue: any issue that says "cvs" now and does not get fixed, remains as cvs even if we release 4.7, then 4.8 then 5.0, then 5.1, ...etc. Later someone has to go thru and mark some of them as no longer applicable, ...etc.
It does not work this way. One bug filed against cvs in the 4.5 days could still perfectly be applicable against current days CVS. The fact that a new release is out, does not mean every bug against the prereleease code is now fixed, or should be fixed in that release cycle.
You're right that they *could* be applicable but odds are they don't. But if the issue is still applicable the original submitter or someone else who encouters it can still re-open it. As Moshe said, it's a good time to clear out the clutter. andrew
andrew morton wrote:
On 1/27/06, Gabor Hojtsy <gabor@hojtsy.hu> wrote:
One related issue: any issue that says "cvs" now and does not get fixed, remains as cvs even if we release 4.7, then 4.8 then 5.0, then 5.1, ...etc. Later someone has to go thru and mark some of them as no longer applicable, ...etc.
It does not work this way. One bug filed against cvs in the 4.5 days could still perfectly be applicable against current days CVS. The fact that a new release is out, does not mean every bug against the prereleease code is now fixed, or should be fixed in that release cycle.
You're right that they *could* be applicable but odds are they don't. But if the issue is still applicable the original submitter or someone else who encouters it can still re-open it. As Moshe said, it's a good time to clear out the clutter.
andrew
Well, I said the version should not be changed to some given version number instead of CVS. I did't say that old bugs should not be closed. Goba
participants (4)
-
andrew morton -
Gabor Hojtsy -
Khalid B -
Moshe Weitzman