|
|
I've created a rough first version that works for us (see attached checkintag.php). It assumes (in this code) that version tags look like <product><version>, where version starts with at least one digit.
We use tags like webenq_3_0, webenq_iicd_3_0_rc1, wa_fr_3_1_7 and it matches those against "tag prefixes" webenq, webenq_iicd, wa_fr respectively, and adds the full tag as a version to the project(s) with that prefix in Mantis.
What you need to do:
- add a varchar field versiontag_prefix to the table project_info
- fill this with the tag prefixes (sorry, no admin interface yet)
- add a call to the script to CVSROOT/taginfo:
DEFAULT /usr/bin/php /path-t0.../core/checkin_tag.php
- start tagging versions :-)
What needs to be done:
- add the field to the project management interface
- move the regular expression for the version tags to config_inc.php
What could be done:
Perhaps introduce a "next_release" version to each project, and have the script automatically update all "resolved" or "closed" tickets marked to be in the "next_release". |
|
|
<giallu> now. Is there any official position on http://bugs.mantisbt.org/view.php?id=6506 ?
<giallu> I would be interested in working on it for my mantis installation at work
<vb123> giallu, I like the idea
<vb123> we should add a "tag" field to the version table. Intially the version tag and name can be the same, but the manager can change the version name later.
<vb123> I think we should make use of custom functions to do the filtering of tags and decide what to do with them.
<vb123> This allows users to program their own rules.
<giallu> moreover, something is needed to mark them as released/unreleased
<giallu> vb123, do you want to track later associations between tags and version names in mantis?
<vb123> yes. The tag should be a property of the version.
<giallu> fair enough
<giallu> about the user thing.
<giallu> I think there should be a mapping between user in CVS/system and mantis ones
<giallu> not necessarily they are the same
<giallu> or stick with a single user like the checkin
<vb123> that's what custom functions are for.
<giallu> so let's see...
<giallu> 1. a cvs tag command is caught
<vb123> we can implement a custom function that maps a name A to A. Then the user can decide to override it to map cvsA to mantisA.
<giallu> 2. a custom function is triggered to map the cvs_user to mantis_user
<vb123> we can also do it through user custom fields. This is not yet implemented, but paulr was working on it at some point in time.
<giallu> 3. another custom function is triggered to add, if needed, the tag to the given project
<vb123> the third option is an configuration array that does the mapping array( "cvsA" => "mantisA", "cvsB" => "mantisB" )
<vb123> Response to 3, the custom function is called with the tag, the function implementation decides whether the tag should be added or not and to which project.
<giallu> At first I thought about using the third approach
<vb123> In Mantis 1.1, configurations can be set via the UI.
<giallu> but all in all, I think the first fits more with mantis
<vb123> Only administrators are able to use the generic UI for the configs stored in the db.
<vb123> My new approach is to implement a custom function that uses a configuration. Users can then use the config 90% of the cases, and for the 10% they can implement a custom function.
<vb123> I mean override the custom function.
<giallu> It's not yet clear to me how this UI for config works... I'm sure it will be later on :)
<giallu> is there a CVS branch I can have a loot at?
<vb123> there is a page that lists all the configs in the db, then the user can set config "x" for project "all or specific one" for user "all or specific one" to type "string/complex/integer" and specific value.
<vb123> In this case the user will set "user_login_map_for_source_control" in project "all projects" for user "all users" of type "complex" to array("cvsA" => "mantisA", ...).
<giallu> this is more clear :) thanks |
