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 <[EMAIL PROTECTED]> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/mantisbt-help
---------------------------------
Looking for last minute shopping deals? Find them fast with Yahoo! Search.-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/mantisbt-help
