View Issue Details

IDProjectCategoryView StatusLast Update
0008334mantisbtchange logpublic2019-06-22 07:32
ReporterBithunter Assigned To 
Status acknowledgedResolutionopen 
Summary0008334: Paginate/Limit Changelog

Changelog can grow until it's a very large (and slow rendering/loading) page. Have it paginated or limited (versions could have a new check to include or not in changelog) would be a nice option.

TagsNo tags attached.


has duplicate 0006903 closedgiallu Break up changelog page 
has duplicate 0006017 closedgiallu Filter change log by specific versions 
related to 0017145 feedback Need to show obsolete versions in Change Log. 




2007-09-05 21:00

manager   ~0015573

I agree about the need for limiting the versions to be included. I can see several approaches for this:

  1. Limit the number of versions shown (e.g. show last 10 versions).
  2. Add a boolean field to versions to indicate whether it should appear in the changelog. This will require a schema change.
  3. Show one version per page. Not good for searching the changelog which I find useful. But there can be an ALL mode which shows all.
  4. Limit the number of versions per page.

I would like feedback about preferences for these options or other possible solutions.



2007-09-06 02:58

reporter   ~0015576

Hi Victor,

I would prefer a paged solution and not a limitation. What do you think about a "Limit the number of ISSUES per page" to dertermine the page-break ?

But now to your other options:

To 1. & 3.: Sometimes we have versions with a very small amount of fixed issues. Maybe in a range within ten. So a visualization using the settings 1 and 3 would be very very short. And not very useful to us.

To 2.: This seems a good solution in general, but for the requirements of our ISO-9000 certification we need to see all changes so this option would always be "ON" for us here. Another thought for your schema change. Have you ever thought of using the severaly bits of an integer "State" value instead of generating a boolean option for each and everything? This could prevent schema changes when you need another "On" or "Off" option in the future. It's a bit of readability against a database change mess.

  1. If you disagree with my suggestion at the beginning of this note, than THIS option would be the one I prefer. All versions and all changes are accessible.




2007-09-06 10:56

reporter   ~0015580

Best choice for me could be to have a issue amount limited page, but including/excluding entire version changelogs, and possibility to see next/previous pages.

If we had version 1, version 2, ... version 10, and each of them has exactly 10 issues solved, a issue limit of 35 should show version 1, 2, 3 and 4 in first page, 5, 6, 7 and 8 in second page, and 9-10 on third.



2007-09-07 04:21

reporter   ~0015587

I totally agree to your example Bithunter! Including the whole version is a very good idea.



2008-04-21 18:56

reporter   ~0017647

Jira is implementing 1. with default to last 3 versions.

Now that we have an Obsolete field, I think we can show a changelog page with the last 3 released, not obsolete versions.

Two links could provide the changelog for

  • all non obsolete versions
  • all versions including obsolete ones

the magic number "3" could be replaced by a configuration option, global or per-user

Issue History

Date Modified Username Field Change
2007-09-05 09:05 Bithunter New Issue
2007-09-05 21:00 vboctor Note Added: 0015573
2007-09-05 21:00 vboctor Status new => acknowledged
2007-09-06 02:58 Ellerbrok Note Added: 0015576
2007-09-06 10:56 Bithunter Note Added: 0015580
2007-09-07 04:21 Ellerbrok Note Added: 0015587
2008-04-21 18:56 giallu Note Added: 0017647
2008-04-22 04:30 giallu Relationship added has duplicate 0006903
2008-04-22 04:50 giallu Relationship added has duplicate 0006017
2019-06-22 07:32 atrol Relationship added related to 0017145