Let upgrade_status know about the Bio --> Content Profile migration

@bonobo: That's upGRADE_status, not update_status. ;)

@sun: bio (and for that matter, nodeprofile) is being replaced with content_profile in D6. I just skimmed the upgrade_status code again and while there's the upgrade_status_moved_into_core() stuff, there doesn't seem to be any logic to support "foo is deprecated in favor of bar" style reporting. Am I just missing it? Seems important for upgrade_status to be able to handle this case, don't you think? Thoughts?

Yes, definitely needed and demanded by some users already.

Original feature request: #298270: Add upgrade status for new major module versions?
Seconding feature request related to Views Bookmark: #303588: Show upgrade paths for deprecated modules
And now this request about Bio/Node Profile.

While I would like to focus on the primary feature request in the other issue, I'm following up on this one, because the queue is cleaned-up and it might show up in your tracker. ;)

I have tried hard to fork as little code from update_status as needed. Upgrade Status re-uses the functionality from Update Status to query drupal.org for available projects and project releases. And Update Status only queries drupal.org for the currently installed modules. This means that we could add a notice for special upgrade paths of contrib modules, but we cannot query drupal.org with the appropriate (altered) set of modules. Like in this case, the user would actually want to see the status of Content Profile for 6.x instead of Bio, which would make more sense in the end. However, I fear that this won't be possible unless we fork update_status completely... :-/

I don't mean to be a stickler about this, but is providing "upgrade paths" in update status really necessary? Wouldn't informing users on the Bio and the Node Profile project pages inform users of the switch?

Content Profile should just be able to migrate the two systems to Content Profile. Once users have upgraded to Content Profile, the work (maybe extra coding) done to tell them to upgrade is now be unused.

Most projects do not do this anyways, when a project becomes dead, at most they provide a link to another module with the same or more features.

I am going to set this to "wont fix" because of the two week lack of postings and the above posts have set the tone about the likelihood of this getting done. Objections welcomed!

@specmav:

a) this is upGRADE status. providing "upgrade paths" is what this module is all about. it just tells you "that thing you're using is now available for D6", or "that thing you were using in D5 is now part of D6 core". It doesn't yet have the ability to say "that thing you're using in D5 is deprecated and has been replaced with foo in D6, which is now available.". again, please do not confuse with upDATE status.

b) all of the relevant projects point to each other, as expected. this is just the "icing on the cake" for sites relying on upGRADE_status to know when the modules they care about are all available for D6. Folks using bio and waiting for upGRADE status to give an all green report will be needlessly waiting forever -- content_profile is already available, even though bio itself will never be ported. of course, if your upGRADE status report was all green with one red row, you'd be smart to go check out that project page and see what you can learn about it.

c) you're not the maintainer -- if sun (the maintainer) said "Yes, definitely needed" then this shouldn't be "won't fix".

d) if every important issue that didn't get resolved in 2 weeks was abandoned, drupal would be a very sorry piece of software. ;)

@dww:

a and b) I stand corrected.

c) I didn't realize sun was the maintainer, from now on I will pay attention. Although I didn't realize the "wont fix" status was solely reserved for maintainers. If that is the case, I will refrain from using it.

d) Very true.

I apologize for jumping the gun. I was going through issues left and right and I didn't see this was moved to the upGRADE status module. I thought someone wanted either the Bio or Node Profile creators to implement this. My post was mainly to tell the issue creator that those maintainers have other issues that should be resolved first (like a stable 6.x release, those kind of things).

@specmav: no problem, thanks for trying to clean up. ;) Re: (C) I'm not saying "won't fix" should be "solely reserved" for maintainers, I was just pointing out that since the maintainer in this case already said "yes", we shouldn't come in and "won't fix" that decision...

I agree as well. Thanks.