There are a few limitations and problems with the current interaction of project* (project and project_release) and update_status. One of them is a fairly serious bug, something that was part of the existing design but that was omitted in the current implementation of update_status. Since we have to fix this problem anyway, we might as well Do It RightTM and fix the other limitations while we're at it. Moreover, time is very short to fix this in D6. Read on for an explanation of the problems and my proposed solution to all of them.
Existing problems
- update_status doesn't warn sites when their current release has been unpublished.
- update_status doesn't understand having multiple recommended versions for a given version of core
- project* doesn't let maintainers indicated that they support multiple branches for a given version of core
- project* doesn't display multiple supported versions for a given version of core
- there some edge cases regarding security releases
Basically, all of the above boils down to two things:
- The logic in update_status where when it decides to warn admins to upgrade.
- The project node UI.
Fundamentally, the problem is that the notion of the "recommended version" is being overloaded to mean too many things:
- The version new users are suggested to download via the project browsing pages.
- What you see on the front page of the project node.
- If people should drop an older release and upgrade because their series is no longer supported
Proposed solution
After thinking about it more, I believe there's still value in the notion of a single recommended release for each core API. However, this needs to be more strictly defined. It should only mean "what version the maintainer thinks new users should download". So, this will be the single release listed with the project teaser on the various browsing pages. This will also be marked as such in the project node and update_status UI. However, update_status will NOT automatically warn you to upgrade if you're running a different version. update_status will only warn you if your release is specifically marked as insecure, abandoned, or unpublished.
So, all we need is:
- Add 2 more terms to the "Release type" vocabulary on d.o: "Insecure" and "Abandoned".
- Fix update_status logic accordingly.
- Use the dev snapshot release nodes to represent a "release series".
I think point #3 would actually make some of the project_release code make more sense, and I believe it'd simplify the project admin UI. If you marked a given dev snapshot node (release series) with "abandoned" or "insecure", we could update all the release nodes from that series the same way. Plus, on the project release editing page, all the series would be listed, so they could mark which ones are recommended for each core, which ones are visible on the project node, etc.
project* would still automatically update the download links and release table stuff with the right version from each series, so admins would still get that for free instead of introducing any more manual effort to the process.
That probably sounds like a lot, but I suspect I could pound out this code in the order of hours, not days. Especially if there was help with reviews, testing, documentation and support, I think this is totally doable in the very near future.
Any comments, suggestions, or volunteers? Please comment here! ;)
Thanks,
-Derek
(With slight edits by Edward)
Comments
I do not think that we
I do not think that we should have multiple recommended versions. Generally I see the recommended version as being a starting point for people hat have not yet installed the module.
With e-Comerce I will have 2 stable versions. People on the older stable version should not be forced to upgrade. Where as people who are starting fresh should really use the recommended version.
Being able to tag major branches as supported/unsupported abandoned would also be nice.
--
Gordon Heydon
Re: I do not think that we
This proposal would have only one recommended version per core API. (Thus, if there are multiple core APIs, there will be multiple recommended versions, but only one will matter to the person because they are only running one core at a time!)
They will not be, unless the older stable version is marked abandoned (at which point it's not stable anymore!) And, assuming they download the recommended version of Drupal, they will also download the recommended version of the module.
I concur.
That's what I said. ;)
Neither do I. Here's what I said:
I believe there's still value in the notion of a single recommended release for each core API.
(Added emphasis)
Again, as I said:
It should only mean "what version the maintainer thinks new users should download"
Seems we're on the same page here, if you read the proposal closely.
I tend to read "recommended version"
I tend to read "recommended version" as applying to a production release. It really depends on the technical savvy of the new user if she even pays attention. My initial testing of Drupal was to download HEAD for nearly all contributed modules. Now that was a trip. "Recommended version" gives a pointer to say, "we told you newbie to use this version".
Some comments
The proposal, overall, is excellent. I have a few questions/comments:
If you don't mind, I'm going to edit some segments of the wiki page for clarity.
Also, project currently doesn't allow
Also, project currently doesn't allow for two different development versions. If I have module foo at version 1 and want to start developing version 2 but also have a dev version of 1 it doesn't display as one of the options.
Example:
foo-6.x-2.x-dev
foo-5.x-2.x-dev
foo-5.x-1.x-dev
The foo-6.x-2.x-dev and foo-5.x-1.x-dev are displayed at project/foo even though the foo-5.x-2.x-dev is displayed properly at project//release.
Extension to release branch node
I think the logical end to this feature request would be to incorporate development snapshots as part of the release branch nodes themselves, and a node by themself.
Backwards compatibility
This is not a very major problem, since update_status is bundled with Drupal 6.x, so only people who specifically installed it will pose a problem. However, it still is worth asking, what are the backwards compatibility ramifications for these format changes?
Pretty sure we could do it without trouble
I'm fairly confident we could change things in such a way that the existing clients (update_status 5.x-2.0 in contrib is widely deployed) would still function, while newer clients would be smarter/better. Basically, we'd leave all the existing attributes exactly as they are, and just add some more attributes that the newer clients would look for and act on.
Patch started, open questions
I've started working on a patch to fix all of this in update.module in D6. See my comments at: http://drupal.org/node/197186
I'd like input on the wording of the UI text there, along with a few open questions about implementation details.
I've also got a wider-reaching question which I wanted to post here...
D) What should the XML look like for the new major/branch-specific attributes?
Currently, there's just this:
<default_major>1</default_major>I'd still include that for backwards compatibility, but I'm thinking the new stuff would look something like this:
D.1) More structured:
<recommended_major>2</recommended_major><supported_majors>
<major>2</major>
<major>1</major>
</supported_majors>
<default_major>1</default_major>
So, 2 and 1 are both supported but 2 is the recommended version for new downloads. These are the only things specified by the project maintainer. default_major is just for backwards compatibility with older update(_status) clients, and is automatically generated by taking the MIN() of the supported_majors.
Alternatively, we could just do:
D.2) More "simple":
<recommended_major>2</recommended_major><supported_majors>2,1</supported_majors>
<default_major>1</default_major>
It's less data, but requires special knowledge to turn supported_majors into an array after parsing the XML...
I'm not sure which is better, I can see benefits either way. Anyone have a reason to pick one over the other?
Thanks,
-Derek
d1
d1 feels more "right" since the data is separate. Whatever the word for "normalized" is in xml, that's it and it feels good to me :)
knaddison blog | Morris Animal Foundation
Another data point
Something else to consider. I just setup project.drupal.org to work like update.d.o so I could have a play pen to try some of this stuff out without breaking the live world. You can do the following to point your D6 test site to p.d.o, instead:
variable_set('update_fetch_url', 'http://project.drupal.org/release-history');Anyway, I tried it both ways, just to see how old clients handle the new XML. Not that it's that big of a deal, but sadly, existing update clients (and almost certainly 5.x-2.* update_status, too) hit a PHP warning in the XML parser on the D.1 approach. Things parse cleanly, even with the old parser, for the D.2 approach.
However, before we let that make our decision for us, I should point out:
- Things still work, it's just a PHP warning.
- Core doesn't have an official release yet, no one should running any D6 core release yet on a live site.
- We'd obviously fix the parser along with the patch, so newer clients won't have any warnings.
- We'll probably turn off E_ALL before the final 6.0 release.
- D5 doesn't have E_ALL compliance, anyway.
...
So, I don't really care, but I wanted to mention it now that I spent the time to find out.
notice, not warning
Sorry I was being sloppy with language. The actual error is:
notice: Undefined index: in /.../core/modules/update/update.fetch.inc on line 208.So, it's a notice, not a warning...
Another (better) reason for D.2: simplicity
Upon further testing, with both 5.x-2.* update_status, and 6.x update, if we go the route of D.2, not only do we avoid PHP notices, we actually don't have to touch the XML parsing code at all. All we'd have to do is a little post processing on the nested array we get back, or just treat this value as a string instead of an array when we actually need it. If we go the route of D.1, we have to teach our crusty XML parser about the new tags, etc, which would slow down the patch and bloat the code a little more.
project maintainer UI to indicate multiple supported branches
Please see the mockups in http://drupal.org/node/203313 in particular http://drupal.org/files/issues/203313-UI-1_table_recommended_snapshot_2.png for ideas on how the "releases" subtab of the project edit tab would look to support this. Feedback welcome. There's also the start of a patch there to implement the changes, so anyone who wants to help out, please join us in that issue. Thanks.
Looks very good.
benjamin, Agaric Design Collective
benjamin, agaric
Patch landed in update 6.0-rc2 and update_status!
Yay! ;)
http://drupal.org/node/197186 was committed to core in time for 6.0-rc2. I backported the patch to update_status, and it's now committed to DRUPAL-5--2 for the 5.x-2.x-dev snapshot (http://drupal.org/node/143593). We're just awaiting a little more testing before we cut an official 5.x-2.1 update_status release.
The project maintainer UI is moving along very nicely, too, thanks to some jQuery help from starbow: http://drupal.org/node/203313
Really, the only major piece missing now are changes to the user-visible project UI (e.g. the download table on the project nodes) to support all the cool new stuff the maintainers can define thanks to #203313. Anyone who wants to help make all this a reality on d.o should read http://drupal.org/node/176776#comment-687299 and help get the ball rolling on that part.
Thanks,
-Derek