Posted by Eric_A on May 18, 2011 at 2:12am
5 followers
Jump to:
| Project: | Drupal core |
| Version: | 7.x-dev |
| Component: | documentation |
| Category: | task |
| Priority: | major |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
| Issue tags: | API addition |
Issue Summary
Contrib developers need this information or they will have big issue queues.
For example, a Drupal 7.0 user will file a bug and some users will confirm the bug and others will state that they do not experience this bug. The maintainer will or will not find out one day that hook_user_role_presave() only existed since 7.1.
Comments
#1
Modules can specify minor version dependencies in their .info files - so core should not allow a module to be installed if the core version is older than 7.1 (or whatever).
IMO this is something that should be maintained on http://drupal.org/project/update/6/7 and via revision control, we can't keep track of all this in the core .api.php files.
However as far as I know we are not tracking this anywhere currently, but I'm downgrading to major - if a contrib module only works with 7.5, and users are using 7.0, they're running an insecure version of core anyway most likely.
#2
Changing title.
Do we just add these to the 6/7 upgrade guide after 7.0 - by definition they are not 7-8 API changes since they are going in 7.x.
It would be good to be able to collate issues like this and add them to release notes. That sounds like a job for #648218: Make API changes in Drupal core be nodes
#3
When coding and looking up function signatures you don't want to be forced to think: "Hey, let's also check the special page to find out which minor version added this function and which minor version added that last parameter."
Or: "Hmm, can I be sure that an entity label callback function always received this useful last parameter. Nope, let's check the special page."
I'd prefer to read this version information in the Doxygen.
(It would be perfect to have API additions and changes rendered in separate (secondary) tabs at api.drupal.org.)
It's very, very important to know that your code will work with 7.5, but not with 7.4.
#4
Here's a, probably incomplete, listing of committed 7.x API additions. Some of these are mentioned in the 7/8 update docs ;-)
When using 7.0, you should not trust the d.o. API docs, i.e.:
#5
Related to uninstallation. As of Drupal 7.2, the main module file is no longer included. If you need to call a function in your own module uninstallation function, you must manually include it, via
drupal_load('module', $module);. Also if your hook_uninstall() is in the module file, it will not be run.#6
Please don't list all the changes on this issue. This issue is about figuring out how to document the changes, not about listing them. Thanks.
#7
Please don't list all the changes on this issue. This issue is about figuring out how to document the changes, not about listing them. Thanks.
True, but if we don't list them here we'll need a separate issue for this. We do need to list them somewhere, somehow now, because the API addition tag (together with the version field) on the referenced issues does not tell us anything about them being 7/8 or 7/7. Here we're only interested in 7/7.
EDIT: if the version is 7.x and the status is fixed and the last updated is after 7.0 then we can be pretty sure it's 7/7 and not 6/7 I guess. (And the API addition tag is new.) So yeah, maybe we don't need to list them...
#8
No, I think that we do need a list somewhere. Relying on a human entered tag is poor form at best, and if the issue reopens, the point of change is lost in the issue queue. And as there is a freeze on API changes (duh), the list should not be that long, so short points here would make sense in the meantime.
I'm in favor of adding an
@sincetag in the function call but the overhead of this would be fairly large for developers so any benefits would be negated by the overhead. So maybe a series of pages, similar to:http://drupal.org/update/modules/6/7 (With any big changes detailed in sub-nodes)
http://drupal.org/update/modules/7 (Only post Drupal 7.0+ updates)
http://drupal.org/update/modules/7/8 (Currently at http://drupal.org/node/1152742 with no alias)
http://drupal.org/update/modules/8
http://drupal.org/update/modules/6/7 has not had any updates since beta 2.
#9
It still might prove to be a not so trivial task to extract the 7/7 API additions from the issue queue.
-an issue might not be tagged API addition. (Here is one that is tagged API change: #1089174: Prepare view hooks do not receive the language parameter)
-issues may be moved back to D8 after backporting when looking for a better fix.
-6/7 API additions may show up in the list of recently updated issues, when being documented. Some of them closed a long time ago, some coming from Needs work.
#10
We now have change nodes -- which are being used now for 7.x/7.x as well as 7.x/8.x updates.
It does require that committers require that change nodes be created, but it seems like they are doing this. So I think this has been resolved.
#11
Automatically closed -- issue fixed for 2 weeks with no activity.