We are using the Scrumboard plugin (https://github.com/mantisbt-plugins/scrum) to manage our four weeks sprints. Each sprint is a version of our project, named i.e. as "Sprint #17". At the beginning of each sprint we decide which issues will be part of the sprint, and assign the sprint-version as the target version of that issue. We have done this for over a year now and the overall feeling is this works
We do not always release a new version to the public after each sprint.
There are, however, two drawbacks of this way of working:
1) In a single sprint there can be issues from the current maintenance release of our product (say 3.4) and form the upcoming new version (say 3.5). If we release a new version, say 3.4.1 its hard to determine which issues are actually solved in the 3.4 version of our product as the changelog will contain both issues from 3.4 and from 3.5
2) When a user wants to report a new issue in Mantis, he has to select a product version but can only see "Sprint #16 or "Sprint #17" etc in the versions-list. He cannot know which version he has to choose.
Our first idea was to stop using the project-versions for our sprint numbers and use tags in stead, but this would require changing the scrum plugin (not impossible, but not preferable)
Major pro for this method would be that it would allow versionnumbers in Mantis to be in sync with the version numbers of our released products.
Does anybody have any suggestions how we can solve this problem?
Thanks