In D6, we have a custom table called {project_release_supported_versions} that records info about branches of development for each project. This is were we store stuff like what branch(es) are supported, recommended, the latest release for each branch (computed automatically), should -dev snapshots be shown on the project page, etc.
We need to decide how we want to handle this in D7. A few possible options I've come up with while working on this:
A) Use a field_collection attached to project nodes. This gives us a fieldable entity that we can add our fields to. Some of them have a hidden widget (e.g. all the entity references to latest/recommended release nodes for each branch) and we populate those programmatically. Others are just plain old checkbox bools or whatever that the project maintainer can currently toggle at node/%/edit/releases. However, we really want the "recommended branch" thing to be a set of radios across all minor versions of the same major version (if on d.o we think of the "7.x" part as the major and "1" as minor), and that's not easy to do with just clicking this together via field_collection. Also, field_collection makes the UI when editing the project node kinda crappy, since if you have a multi-valued field collection, and it contains any required fields, you can't just edit the project without removing the default new field_collection it gives you. This is probably a bug in the field_collection queue, I'd need to search.
B) Basically keep what we have now. In some ways, this is a bit crappy, but our needs for this are fairly Special(tm) and trying to bend field_collection to our will might end up being harder than just keeping our custom code for this. Sadly, if we go this route, we have to keep/port/maintain a bunch more views code than I was hoping for, in addition to the DB table and all the code to deal with it.
Either way, we desperately want to kill the whole insanity with "API compatibility tid" + version_major as the key into this data. We just want a nice happy "branch identifier" string or something. I'm honestly still a bit on the fence about the right way to represent this. :/ We certainly need to be able to figure out what branch a given release is from, so that when a new release is out, we know what branch to update the "latest release" info for, etc. But, I hate the idea of using tid + major like we do in D6. Down with taxonomy magic in project_release!
Comment | File | Size | Author |
---|---|---|---|
#1 | 1612050-1.project-branch-field-collection.txt | 9.75 KB | dww |
Comments
Comment #1
dwwMostly as a backup, here's the field_inspector output from the field_collection I clicked together when starting down path A. This would need to be folded into project_release.install and includes/project_release_node_type.inc to actually be a useful patch, but since I already spent the time trying to define this as a proof-of-concept, I wanted to share the results here for backup and possible collaboration if anyone else wants to look into this, too.
Comment #2
drummA version of the
field_release_branches
landed in the 1551384-release-deep-port branch, namedfield_project_has_releases
with #1546092: Add a field to control if a given project node has releases.The rest of the fields look generally good, but I'll pull them in as I understand them.
I like the idea of getting away from taxonomy magic. It looks like the list of available API compatibility versions, like 6.x, 7.x, 8.x, is used frequently in the code. I think we want a project node type setting for this. Maybe a text area next to the "Download link base URL" field, which sets the options one-per-line. Then, release nodes either have a select field for API compatibility, with
#options
from the project node type; or it is used in validation forfield_branch_identifier
.Comment #3
drummI went ahead and added a per-release-node-type setting for API compatibility options, http://drupalcode.org/project/project.git/commit/9a24745, as described in #2. I'll work on using it throughout the code.
Comment #4
drummdww and I talked about this. What we tentatively settled on is
project_release_supported_versions
as a custom table. Do a straight upgrade of the same UI, views integration, etc.project_release_supported_versions
and anywhere else needed. The version string is already in the branch.This will allow us to move forward with the upgrade with an architecture that we can live with. Rearchitecting it to be more-cleanly field-based is something we can think about doing after the 7.x upgrade.
Comment #5
dwwAlso, we agreed to just keep using taxonomy for the "api compatibility", and we'll revert commit 9a24745 from #3. It's kinda crappy to use taxonomy, but there are a *lot* of places on both releases and projects that use that, and it's just going to be less total work to basically port the system we have now.
Ideally, while we're porting, we could be untangling the dependency on taxonomy so that sites which don't care can just use simple major.minor.patch versions and not have to think about or use the taxonomy stuff. But, if that slows us down too much, we might just have to live with the dependency for now and circle back later (hopefully!)...
Comment #6
dwwp.s. We also discussed more or less keeping the "version string format" setting, but using it in the opposite direction -- to parse the single version string field from the release node to figure out what branch it belongs to for the purposes of {project_release_supported_versions}. Or something. Exposing a regexp to end-users seems evil and wrong, and perhaps the existing token-based system (with the funky punctuation prefix stuff) is the best UI for it.
Comment #7
drummI've gotten into rewriting this
I've already made field_release_version_major a field for that condition, and maybe other uses. I've been thinking about a few ways to tackle the commented out order bys:
Comment #8
drummI settled on making fields for minor, patch, and extra. I committed these to the branch along with updating various code in the node save path.
Since release nodes are saving well, I think I may be able to change the status.
Comment #9
drummMarking this as fixed since 1551384-release-deep-port has been merged.