See http://drupal.org/project/issues/taxonomy_filter. Any issue tagged as 7.x-1.x-dev that is older than 24 weeks (as of this issue creation) should have a tag of 6.x-1.x-dev.

Take a look at the node IDs and node creation dates on the 6.x and 7.x dev releases. The former is: node/995070 posted by solotandem on December 10, 2010 at 4:45pm and the latter is node/96252 posted by styro on November 11, 2006 at 4:14am. These are obviously flipped and I suspect they relate somehow to the process involved in adding a branch to CVS. Around December 10, the CVS HEAD became 7.x and a 6.x branch was created. If I recall, Dave Reid may have manually intervened to create the new branch.

This looks like the 6.x release node was retitled to be the 7.x release node and a new node was created for the 6.x-dev release. So the release node references on the issues were not updated to point to the new 6.x-dev release node.

Any chance the release nodes could be retitled so 7.x has the greater nid?

Comments

dave reid’s picture

dave reid
he/him
Primary language English
Location Nebraska USA
commented

We can't just swap around release nodes - once they are associated with a branch they are locked to that branch. The solution as always when this happens is having to fix the versions for each issue manually.

dww’s picture

dww
we/he/they
commented
Category: bug » support
Status: Active » Closed (won't fix)

Yeah, what Dave said. Whatever wonky thing happened historically with these release nodes isn't a bug in project_issue. I was always careful when dealing with release nodes and CVS trickery to avoid problems like this if possible, but what's done is done. At this point, there's nothing I can do to help -- you just have to clean up your queue. Maybe help out with #1093650: Provide VBO support for issue management first. ;)

Sorry,
-Derek

boombatower’s picture

boombatower commented
Status: Closed (won't fix) » Active

So if you have 6.x-1.x dev pointing to master then you should simply change the branch it points to as you do in vcs.

So 6.x-1.x points to the 6.x-1.x instead of master. Then the issues aren't messed up and everyone is happy. You then create a new release for the 7.x branch which could (for CVS terms) be master since it represents a new release/branch. This is how it will work in the future with releases since all branches will be named 6.x-1.x, 7.x-1.x. You will always create a new release...the same makes sense both abstractly and practically for historical changes.

Hosing 1,000s of issues on loads of contrib projects is not helpful and is in fact extremely un-useful. So the simple solution is the enable the text field where you can end the branch and replace it with the select that you have when creating the release. I would bet it involves the removal of code that switches between the two.

Side note: #2 seems to point to a feature request to do exactly what #1 states is impossible which is rather interesting (they are just IDs in database, nothing is locked).

boombatower’s picture

boombatower commented
Title: Issues with 6.x-dev version tags now display with 7.x-dev version tags » Allow releases to change branch/tag they point to
Category: support » task
boombatower’s picture

boombatower commented
Project: Project issue tracking » Project
Component: Issues » Releases
solotandem’s picture

solotandem commented

By way of example, consider the Coder project with dev releases for D5 through D7. The nids of the release nodes are in sequential order by release, with 5.x having the least nid. In contrast, the now 7.x dev release for Taxonomy Filter has the least nid of all its releases. So whatever you claim to be the procedure, it wasn't applied consistently in these two cases. My take from this is that the Coder project did not have to reassign the release node on all of its issues tagged with the heretofore latest dev release when a new dev release was created. I don't have many issues to fix on TF, but all projects taken together would be an overwhelming number to fix.

dave reid’s picture

dave reid
he/him
Primary language English
Location Nebraska USA
commented
Status: Active » Fixed

Holy crap this is still dragging on. I think I did it wrong in this case and I'm SORRY. The proper method shouldn't result in messing up any issues. I've volunteered to help move issue versions for any projects I've messed up in IRC already.

solotandem’s picture

solotandem commented
Status: Fixed » Active

Fixing the issues in TF (or any other project) is no longer the topic. The messed up issues is the symptom of the bigger problem. The inability for the project maintainer to point a release node to a different branch is the issue. This is still not doable. (Is it more than marking the release as dirty as it does whenever a commit is made, and recreate the release?) As noted in #3, enabling the select form element probably involves the removal of code (for the exception handling).

dww’s picture

dww
we/he/they
commented
Status: Active » Closed (won't fix)

See all of these for background:

#953916: Proposal: Ditch the ability to have release nodes pointing to HEAD/master
#994244: Rename the master branch to a proper version branch
#1061592: Re-add special-case for editing release nodes pointing to master/HEAD to allow maintainers to move to a real branch

This all works as expected if handled right in the first place. Dave is sorry he didn't handle it right in this particular case, and has apologized. But there's really no way we're going back on all these decisions from the Git migration at this point.

Sorry,
-Derek

boombatower’s picture

boombatower commented

So based on #1061592: Re-add special-case for editing release nodes pointing to master/HEAD to allow maintainers to move to a real branch seems to indicate that you can do exactly what was asked (as in edit), when points to master? If so then this is indeed solved, otherwise where are the docs for this as after reading the issues they mostly discuss what the new standard for branch names will be.

Not trying to get on Dave's case as based on responses it seems to have come across that way.

dww’s picture

dww
we/he/they
commented

@boombatower: Yes, but I don't see any release nodes pointing to 'master', so I'm not sure what you mean...

boombatower’s picture

boombatower commented

Assuming they must have all been fixed recently due to #1076616: Projects should have "master" renamed to appropriate branch. So seems we are all on the same page just didn't realize that. Aside from the mistake, the initial responses all indicated that doing it the way that it is apparently supposed to be done (and we were advocating) was impossible.

These last responses seem to contradict that and if there are no more master releases then that is even better.

dww’s picture

dww
we/he/they
commented
Status: Closed (won't fix) » Closed (works as designed)

I must admit to not fully groking the original report and your situation. I'm glad to hear it's resolved.

The goal is to completely eliminate "master" release nodes eventually. You can't create new ones. You can migrate exiting ones to properly-named branches. So, it's just a matter of time before they've either all been migrated or those releases/projects that still have release nodes pointing to "master" are abandoned/irrelevant.

Cheers,
-Derek