Right now, cvs.module does all sorts of unholy things to alter the project_release node form to turn it into a multi-step form so that you first select a CVS tag you want to base your release on, and then you land on the main release node form with all the version info pre-filled and unchangeable.
We need something similar for versioncontrol_project, ideally, in a way that's not too tightly tied to any given VCAPI backend. Ideally, there's just a way to have VCAPI define the available tags/branches for a given project, and an easy way for sites to define how to map those tags to version numbers.
Then, versioncontrol_project does all the crazy form altering. If we need to change the project_release form to make this any easier, we should. ;)
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | 850142-12.vc_release_node_add.patch | 12.01 KB | dww |
| #11 | 850142-11.vc_release_node_add.patch | 4.79 KB | dww |
| #6 | 850142-6.vc_release_node.patch | 7.75 KB | dww |
Comments
Comment #1
dwwForgot the "git phase 2" tag.
Comment #2
sdboyer commentedThis feels like it might have a duplicate somewhere, so bumping it so that dww will see it :)
Comment #3
dwwBlocked on the outcome of #953916: Proposal: Ditch the ability to have release nodes pointing to HEAD/master
Comment #4
int commentedComment #5
dwwI'll be working on this, but not in the next few days. Still, figure I should assign myself so there's no duplication of effort. The only thing blocking progress on this now is my availability to work on it, and unfortunately, I've got another critical task to attend to, first.
Comment #6
dwwInitial patch. Sorry I didn't post this sooner, but the net at my new location is quite sucky. :(
This is basically the cleanup needed based on #953916: Proposal: Ditch the ability to have release nodes pointing to HEAD/master
Lots more to do in here, but this is at least a step in the right direction.
Comment #7
sdboyer commentedYep, that all makes sense. And reminds me how much of what's in there is really, really vcapi-1.x focused. I'm gonna let you run with this one, but I'll have a look at versioncontrol_release today to see if anything really jumps out as a gotcha that you might get blocked on. Hopefully make it a little easier.
Comment #8
sdboyer commentedtagging and changing status, since it was a first pass.
the only problem I actually did see was that you left your debugging lines in there :)
Comment #9
dwwRemoved the debug line and committed to HEAD. This is now blocked (very temporarily) on #1015296: Add a pluggable system for mapping VCAPI branch and tag objects to project_release version objects.
Comment #10
dwwThe following are all fixed, so this is active again:
#1015296: Add a pluggable system for mapping VCAPI branch and tag objects to project_release version objects
#1019162: port vc_release to VCAPI V2
#1019244: Add a versioncontrol_release label_version_mapper plugin for d.o-specific mapping of Git branches and tags to d.o releases
Also, I split this out to a separate issue, since it's a totally different code path with different logic and requirements:
#1019294: Integrate VCAPI with project_release node edit form
Comment #11
dwwWHOOT! This is working locally! It even filters out VCAPI labels that already have release nodes pointing to them. ;)
Comment #12
dwwBetter patch:
- Handles setting the 'rebuild' bit appropriately or not.
- Fixes a ton of PHPDoc formatting bugs from the jpetso days.
- Cleaned up some other comments and made the code more legible in a few spots.
Comment #13
dwwCommitted #12 to HEAD! ;)