once the new release system goes live, and releases are real nodes (http://drupal.org/node/83339), we need a branch-aware notion of what the "default" or "latest" release should be for a given version of core. instead of a single "download default release" link (which will be a pain for maintainers to keep updated in its current form), we should:

  1. have a {project_release_default_versions} table, with pid (project id), tid (compatibility API term id) and major version number. by default, major = 0. on the project edit tab, we'd have a little table-based form. we'd iterate through all the release nodes for the project, and for any API compatibility tid values that have > 1 major version number, there'd be a row in the table, with a drop-down selector for the different values of major. so, if you only have 1 branch compatible with 5.x, there's no need for a row, but if you've got 2, you get to select which major version should be the "default".
  2. based on the values in this table, the "download latest release" table on the project node would be automatically discovered (i.e. so that if a project has a dev and a stable branch for 4.7.x, the default download link always points to the latest from the stable series, even if there's a newer development release.
  3. this DB table would also solve the problem of what release to link to from the project browsing pages when you filter by a specific version (currently, we just grab the latest release compatible with the selected version of core, but we want to limit it to the right stable branch, etc).
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

pwolanin’s picture

#3 doesn't even seem to be true. I've been playing making releases tagged as DRUPAL-4-7--1-0 for my projects. On the project page (http://drupal.org/project/Modules/name) the download link is still always pointing to the snapshot- e.g. 4.7.x-1.x.

this project has a 4.7.x-1.0 release (and the release node, at least, is newer than the snapshot release even though they point to the same revision in CVS):

http://drupal.org/project/og_mandatory_group

dww’s picture

hrm, yeah, i see what you mean. these browsing pages are some of the most complicated and hard to understand parts of project.module. i spent nearly 3 hours one day with nedjo just trying to understand the stuff while porting to the new system. there are clearly a few lingering bugs in there. :( anyway, yeah, i'll see what i can do about this, either by just fixing it when implementing this issue, or via a seperate issue (or set of issues) to deal with the current bugs.

pwolanin’s picture

For some reason, the correct links are shown for my 5.x-beta releases on the 5.x filtered version of that module-by-name page. However, none of those projects are branched for 5.x - I just made the release off the trunk.

dww’s picture

that's because all this core compatibility filtering stuff is taxonomy-based:
http://drupal.org/node/83339#comment-144908

pwolanin’s picture

Any further thoughts on this problem? It almost seems as though the automatically generated releases from the head of each branch need a flag or weight so that they appear after any user-generated releases. Maybe the default release could also get a very low weight (though this suggests the need for a per-core API ?

FYI, from the module list page the download link for project module is 4.7.x-2.x-dev

dww’s picture

Any further thoughts on this problem?

nope, what i wrote in the original post still stands as my current best design for a solution...

It almost seems as though the automatically generated releases from the head of each branch need a flag or weight so that they appear after any user-generated releases. Maybe the default release could also get a very low weight (though this suggests the need for a per-core API ?

release nodes already know if they're official releases or snapshots, so we could easily split up the page into offical releases at the top and snapshots below. that'd be pretty trivial. however, i hate the existing /node/[nid]/releases page. it's a mess, and needs lots of work, e.g:

http://drupal.org/node/89535
http://drupal.org/node/89537

i don't think that page is going to be very useful in the end. i'd rather just fix the main project node so that you get a table of current releases for each "active" branch (http://drupal.org/node/89539) and then no one ever has to see/sort through the "all releases" page unless they're really curious or digging for something historical for some reason.

FYI, from the module list page the download link for project module is 4.7.x-2.x-dev

right, that's exactly the problem i'm talking about in point #3 in the initial post...

as a special-case hack for d.o for right now, we could just limit things to the 1.* releases for the browse-by pages. that way, you'd get the 4.7.x-1.0 release, even if a 4.7.x-2.0 is later, but it'd jump to 4.7.x-1.1 as soon as that was created... however, if i was going to spend the time to get this working and tested, i'd rather just fix the problem for real as described above. ;) it shouldn't be *that* painful to get right, honestly.

dww’s picture

here's a first step: the DB schema side of things.
i haven't touched any code to use it, but i figured i'd get a patch at least started...
this has the nice property of correctly populating the table with all the existing default versions.
so, if someone's got a 4.7.x-2.* release as the default for their module, it'll add ([pid], [tid], 2) as the entry for that module, otherwise, it'll use '1'.

so, all we need now are:

  1. admin UI to manipulate this data for each project (so you can select a default major version for each core compatibility term, and so you can select the default core compatibility)
  2. fix the download link (or better yet, just implement http://drupal.org/node/89539)
  3. fix the SQL in project.module that's finding the "Download" link when you filter by a version.

;)

we should probably store the default core compatibility term in the {project_release_projects} table, not {project_projects}, and drop the "version" field from {project_projects}...

dww’s picture

Version: 4.7.x-1.x-dev » 4.7.x-2.0
FileSize
7.72 KB

here's another patch against project_release.install which adds a new "default_version" field to {project_release_projects} (rendering the "version" field in {project_projects} obsolete). this field just holds the taxonomy id that should be considered the "default" version (e.g. when browsing by all versions in the modules pages, or to use for the default download link (or to have a prominent place in the download table once http://drupal.org/node/89539 is done). based on this tid and the {project_release_default_versions} table (which tells you the major version (aka CVS branch) to use for a given project/tid pair), we can find the latest release from the appropriate branch.

so, the schema is almost entirely done. however, the project_release_update_1() that modifies the schema and migrates the data still has 1 minor problem: it screws up populating the {project_release_default_versions} table in cases where a project has more than 1 branch for a given tid (which is exactly the case we need this table for in the first place). ;) i'm just too tired to get the SQL right, but i suspect there's a fairly trivial solution once i look at this with fresh eyes. i just wanted to post a new patch here in case anyone else wants to take a look and help out. ;)

thanks,
-derek

dww’s picture

after discussion w/ webchick, it seems that the notion of the "default core version" for a given module is dumb and wrong. if you look at the project node, you want to see the latest release for all supported/active versions of core (http://drupal.org/node/89539). if you're looking at the project browsing pages, when you filter by a core version, you should only see projects (and download links) to releases compatible with that version of core. if you're filtering by all versions, the project teasers should have a tiny table of download links, just like the project nodes do. this actually simplifies all this schema crap quite a bit, since we don't have to mess with the "default_version" (which was really going to be a tid) in the {project_release_projects} table, and all the hoops i was jumping through to populate that correctly. phew.

also, with a little help from moshe and a less sleep-deprived me, i got the SQL working for the initial populating of the{project_release_default_versions} table.

i'm pretty happy with the schema now, and project_release_update_1() is both simpler, and actually works. ;)

now that there's a patch for http://drupal.org/node/96971 (needs review), i can finally work on the admin UI for this issue. once that's done, i can finish up the download table on project nodes, and at long last, fix the "Download" link on the project browsing pages...

dww’s picture

screenshot of the draft of the admin UI. this is on the "releases" subtab of the project node's edit tab. this screenshot (and the forthcoming patch) assume that #96971 : make better use of tabs and subtabs on project nodes would be committed. any initial thoughts/feedback on the UI? is anyone going to be able to understand what this is about? how could it be clearer?

thanks,
-derek

dww’s picture

Status: Active » Needs work
FileSize
17.2 KB

here's the patch that makes the previous screenshot possible. this still needs work, since you can't save any changes on that UI (haven't gotten around to implementing that part, yet). ;) but, it's mostly there, so if anyone wanted to take a stab at improving the UI, they could at least tweak with the presentation, text, etc. for now, the patch includes the patch from http://drupal.org/node/96971, but it'd like to just commit that soon and keep this patch as small/clean/self-contained as possible.

TODO:

  1. improve/finalize UI
  2. expand schema to store default release type
  3. save values from this UI into {project_release_default_versions} table
  4. properly set default values in the UI based on {project_release_default_versions}
  5. fix SQL that generates download links from project browsing pages to use this data
pwolanin’s picture

The screenshot looks pretty good, though i'm not sure you'd want the customization of version strings available on Drupal.org. Seems like a recipe for confusion (is there a permission to make this accessible or not?). I see, however, that for some other uses of the module it could be handy. Is there a site-wide version of this version format string definition (i.e admin-defined default)?

dww’s picture

oh whoops, sorry for the confusion. you only see that option if you have "Administer projects" permissions, which i happened to have with the account i used to generate that screenshot. normally, you'd just see the "Enable releases" checkbox and the "Default versions" table.

dww’s picture

oh, and in case it's not clear for the d.o case, only about 10 people are in a role with that permission. ;) not even the usual "Content administrator" folks have it, only extra-special site admins...

dww’s picture

after more input from webchick and sepect in IRC, we decided this whole "release type" stuff is needless complication. once you start making official releases for a given branch, you'll always get the most recent official release as the default download. only if there are *no* official releases will the dev snapshot be listed.

also, i moved the version format and the "enable releases" checkbox into a collapsed "Advanced options" fieldset.

finally, i added a '#tree' => TRUE to the form array so that we get all the unique values of the different form elements (all that remains is the major version) for each compatibility term. this still doesn't save the values, nor use them anywhere else, but it's closer (and simpler). ;)

dww’s picture

screenshot of latest patch

dww’s picture

getting really close... ;) all the values from the UI are now stored in the DB, the UI properly shows the currently saved values as the defaults, etc. i fixed project_release_update_1() to handle the case where there's more than 1 major version for a compatibility term that doesn't match the existing default version. this also populates {project_release_default_versions} if we're adding the first release of a project for a given compatibility term.

so, as far as i know, all that's left is:

  1. actually using this data for the download links.
  2. making things sane when taxonomy is disabled or there are no terms in the compatibility vocabulary.

i'd be willing to punt on #2 until after this goes live on d.o, since porting project* to 5.0 is more important. however, i *really* want to fix these damn download links and fix these other project node UI issues (e.g. the download tables)...

dww’s picture

Status: Needs work » Needs review
FileSize
17.42 KB

woohoo, kjartan gave me the RTBC in http://drupal.org/node/96971 which is now committed, so this patch can move forward more cleanly, just focusing on the changes for this.

after struggling with the crazy giant SQL query to generate the project browsing pages, and trying to get help in IRC, we never came up with One Monstrous Query(tm) to do it all. :( so, we're still doing a separate query to get the right download link for every project that has more than 1 release for the selected version of core (just like now). but, at least it works and honors the values from {project_release_default_versions}. ;)

since i'm not 100% sure that the {project_release_default_versions} is getting initially populated in all the cases, i'm using a LEFT JOIN to make sure we still have something reasonable if there's nothing in the table. this could certainly be optimized into an INNER JOIN if we can be sure we always have a value in {p_r_d_v}...

having the cool little table of download links on the teasers when you filter by [all] versions will have to wait for http://drupal.org/node/89539 (coming soon).

dww’s picture

whoops, i diffed against the wrong copy of project.module in my workspace. that one had a syntax error. this one is better. ;)

pwolanin’s picture

Does this code handle the case that I can currently make (for example) a release by tagging my current HEAD as DRUPAL-5--1-0 without having made a DRUPAL-5 branch?

dww’s picture

yes.

dww’s picture

the last patch had a stale description for the default releases table from a previous iteration of the code. this is an attempt at better language.

dww’s picture

after a little FAPI wisdom from chx in IRC, here's another version that simplifies the rendering of the table by using '#theme' for the '#type' = value elements we actually want to render.

dww’s picture

even smaller: just use '#type' = markup and '#input' = true on those elements. ;)

dww’s picture

Status: Needs review » Fixed

after a glowing review from chx in IRC, we decided to go with patch #23 (since theme_markup() doesn't check_plain() for us, and there might be cases where we need that, e.g. sites that don't use cvs.module and allow users to input version info directly). committed to DRUPAL-4-7--2.

dww’s picture

Category: task » bug
Status: Fixed » Needs review
FileSize
2 KB

whoops, this pukes in project_release_project_edit_form_submit() if there are no releases. tee hee. ;)

dww’s picture

Status: Needs review » Fixed

committed to DRUPAL-4-7--2 and installed on d.o.

Anonymous’s picture

Status: Fixed » Closed (fixed)