From: Jennifer M. <jm...@ps...> - 2008-01-23 14:05:17
|
This is the first in what will probably be a continuing series of emails in which I would like to bounce some ideas off people. Please let me know if this type of thing is better addressed on the developer list. We're currently on Mantis 1.0 rather than 1.1. I plan to upgrade within the next month or so once I finish integrating some of our customizations into 1.1 and building a new feature that was requested by my group. We use Mantis to track issues in a third-party application that is updated on a near-weekly basis by our own internal development staff and monthly by the vendor. At this time, our development staff isn't using source control (I know, don't ask as I'm not part of that team) so there is no source control to tie to Mantis. We also don't have build numbers, either internally or supplied by the vendor. At the moment, we're using this naming convention for updates: major version.minor version updater date OR major version.minor version GA (for initial releases) So we wind up with a lot of version names like the following: 7.1 PSU 1/30/2008 update 7.1 PSU 1/23/2008 update 7.1 AL 1/2007 update 7.1 GA We have issues from 6.3, 7.1, and 7.2. As you can imagine, the list has become quite large. We currently have 87 versions. We use these in the "fixed in version" field. This is fine. The list is large but the recent versions sort to the top so they're easily accessible. The problem is the "product version" field. For various reasons, the update version is rarely entered into the "product version" field. What we really want to appear in that field is just the initial release: 6.3 GA, 7.1 GA, 7.2 GA, etc. As the list of updates becomes ever-longer, it becomes increasingly difficult to locate these in the list and more annoying to scroll through them. I've kicked around a few ideas about how to solve this. I can't change how the developers work, unfortunately. I could use custom fields instead of or in conjunction with the version fields, but would prefer not to as that would prevent any functionality associated with the versions from working properly. I could customize Mantis so that only specific releases appear in the product version field, which is the solution I'm leaning toward at the moment. I'm not sure exactly how I plan to do this just yet but possibilities include the ability to indicate whether or not a release should appear in product versions or not. This may be something that can be accomplished with plugins. I'm curious how others handle this situation. Is there something obvious that I'm missing? Thanks, -J. |
From: KM <in...@ya...> - 2008-01-23 15:12:58
|
Doesn't really solve your problem - but one thing we did when using mantis is to use the project as the version. It helped us look at things in more organized "sections" so to speak. e.g. MyProj 1.0, MyProj 1.1, etc. Basically at the end of one version/release/project, any open issues are moved to the next one - etc - basic stuff. But then you as the administrator could probably update the product version at another time - Unless as you said you want to change the code to do what you want. just an idea for organization - but sorry can't help you with the exact problem. KM Jennifer Mullen <jm...@ps...> wrote: This is the first in what will probably be a continuing series of emails in which I would like to bounce some ideas off people. Please let me know if this type of thing is better addressed on the developer list. We're currently on Mantis 1.0 rather than 1.1. I plan to upgrade within the next month or so once I finish integrating some of our customizations into 1.1 and building a new feature that was requested by my group. We use Mantis to track issues in a third-party application that is updated on a near-weekly basis by our own internal development staff and monthly by the vendor. At this time, our development staff isn't using source control (I know, don't ask as I'm not part of that team) so there is no source control to tie to Mantis. We also don't have build numbers, either internally or supplied by the vendor. At the moment, we're using this naming convention for updates: major version.minor version updater date OR major version.minor version GA (for initial releases) So we wind up with a lot of version names like the following: 7.1 PSU 1/30/2008 update 7.1 PSU 1/23/2008 update 7.1 AL 1/2007 update 7.1 GA We have issues from 6.3, 7.1, and 7.2. As you can imagine, the list has become quite large. We currently have 87 versions. We use these in the "fixed in version" field. This is fine. The list is large but the recent versions sort to the top so they're easily accessible. The problem is the "product version" field. For various reasons, the update version is rarely entered into the "product version" field. What we really want to appear in that field is just the initial release: 6.3 GA, 7.1 GA, 7.2 GA, etc. As the list of updates becomes ever-longer, it becomes increasingly difficult to locate these in the list and more annoying to scroll through them. I've kicked around a few ideas about how to solve this. I can't change how the developers work, unfortunately. I could use custom fields instead of or in conjunction with the version fields, but would prefer not to as that would prevent any functionality associated with the versions from working properly. I could customize Mantis so that only specific releases appear in the product version field, which is the solution I'm leaning toward at the moment. I'm not sure exactly how I plan to do this just yet but possibilities include the ability to indicate whether or not a release should appear in product versions or not. This may be something that can be accomplished with plugins. I'm curious how others handle this situation. Is there something obvious that I'm missing? Thanks, -J. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ mantisbt-help mailing list man...@li... https://lists.sourceforge.net/lists/listinfo/mantisbt-help --------------------------------- Looking for last minute shopping deals? Find them fast with Yahoo! Search. |
From: Jennifer M. <jm...@ps...> - 2008-01-23 15:43:21
|
On Jan 23, 2008, at 10:12 AM, KM wrote: > Doesn't really solve your problem - but one thing we did when using > mantis is to use the project as the version. It helped us look at > things in more organized "sections" so to speak. e.g. MyProj 1.0, > MyProj 1.1, etc. Basically at the end of one version/release/ > project, any open issues are moved to the next one - etc - basic > stuff. > > [...] > > just an idea for organization - but sorry can't help you with the > exact problem. It's a good idea. We already have subprojects (bugs, enhancements, and user-requested enhancements). I hope to eliminate use of the bugs and enhancements subprojects in 1.1 and use categories instead (moving the current categories to tags). We might be able to implement this then. Unfortunately, our vendor sometimes takes several years to fix bugs so we'd need to maintain the category list for all of the version projects. That would still simplify things. Thanks, -J. |
From: Jennifer M. <js...@re...> - 2008-01-23 15:35:42
|
On Jan 23, 2008, at 10:12 AM, KM wrote: > Doesn't really solve your problem - but one thing we did when using > mantis is to use the project as the version. It helped us look at > things in more organized "sections" so to speak. e.g. MyProj 1.0, > MyProj 1.1, etc. Basically at the end of one version/release/ > project, any open issues are moved to the next one - etc - basic > stuff. > > [...] > > just an idea for organization - but sorry can't help you with the > exact problem. It's a good idea. We already have subprojects (bugs, enhancements, and user-requested enhancements). I hope to eliminate use of the bugs and enhancements subprojects in 1.1 and use categories instead (moving the current categories to tags). We might be able to implement this then. Unfortunately, our vendor sometimes takes several years to fix bugs so we'd need to maintain the category list for all of the version projects. That would still simplify things. Thanks, -J. |