Closed (duplicate)
Project:
Boost
Version:
5.x-1.x-dev
Component:
Miscellaneous
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
26 Oct 2008 at 00:54 UTC
Updated:
6 Sep 2009 at 08:16 UTC
Hi Arto,
I beleive that issues reported for a particular version of a module should not be marked as fixed just because they have been fixed in a different version of the module.
If a issue is reported in version 5.x-1.x-dev of the module then unless the issue has been fixed in that version..the version of the issue should not be changed and marked as fixed.
It helps give the user visibilty of what problems a partcular version of a module has and helps the community try and fix things maybe by porting changes back to an older version.
Just my suggestion.
Comments
Comment #1
Arto commentedWell, that depends. The thing is, I will not personally be doing any further development or testing of the 5.x branch. The only commits I will make to that branch are RTBC patches that are clear in scope and purpose, easy to review, syntactically valid, and clearly do not break anything. Hence we are effectively without a 5.x maintainer right now, and unless someone with CVS access volunteers for that job soon, I'm going to have to mark the 5.x releases as "unsupported".
In view of this context, it makes perfect sense to either indiscriminately close out 5.x issues, or else move them forward to the 6.x version of the software. (Also, it doesn't make life any easier for me in getting anything done for the 6.x branch if the Boost issue queue is clogged up with issues for which it isn't immediately clear whether it was already implemented in 6.x or not.)
Let's do the same as with Drupal core: as I move issues forward to 6.x, I will continue marking them as fixed when they have been committed to that branch. However, anybody with a vested interest in backporting the issue is free to do so by reopening it, assigning it to themselves (this is very important so that I can see from the issue queue that I don't need to come back to it until it has moved into RTBC status), and then rolling up a 5.x patch and getting some "works for me" comments from other users, after which the issue can be marked RTBC for 5.x.
I will be periodically committing any 5.x branch RTBC patches done in this fashion, but it'd be better yet if somebody explicitly steps up to take care of 5.x in which case we can revise this policy for the better (from the 5.x users' viewpoint). But right now the reality is that 5.x is unmaintained.
Comment #2
mikeytown2 commentedMoving this to #454652: Looking for a co-maintainer - 5.x