View Issue Details

IDProjectCategoryView StatusLast Update
0003638mantisbtfeaturepublic2004-09-12 08:27
Reporterale Assigned Tovboctor  
PrioritynormalSeverityfeatureReproducibilityalways
Status closedResolutionfixed 
Fixed in Version0.19.0a1 
Summary0003638: the bugtracker should be able to produce a changelog
Description

hello,

it would be interesting to have a page wich would summarize all the bugs resolved per day in the format you use here:

http://www.mantisbt.org/changelog.php

using the bug number and the description... copy pasting from there would then produce a simple changelog!

thank you for your fine software!

alessandro

p.s.: as for the implementation, i think a new table could be preferable over a dynamic generation of the result... but i'm not that sure of it...

TagsNo tags attached.
Attached Files
bugfixlist.zip (1,622 bytes)

Relationships

related to 0004218 new Issue found/fixed & version/build relationships with Changelog 

Activities

vboctor

vboctor

2004-03-24 06:52

manager   ~0005250

I think this is a useful feature, however it requires a lot of thought:

  • Which bugs should be included in the changelog? public-only/all?
  • When should a bug be included in the change log? When it is resolved? closed? or maybe when it is marked as tested (an example of a custom status).
  • What format of changelog to use? Group by release or group by release and group by date?
  • Should changlog be generated as html with hyper links to the actual bugs?

However, I think it is to be generated on request, and not stored in a table.

ralfiii

ralfiii

2004-03-24 11:03

reporter   ~0005257

I agree, this would be a really GREAT feature!

But you will need to include a "fixed in version" field! (Which would be helpful anyway)

My thoughts to your questions:

  • Which bugs should be included in the changelog? public-only/all?
    I don't care, we only use public bugs. But for someone who CAN see private bugs you might want to include an option like "[ ]include private bugs in log"

  • When should a bug be included in the change log? When it is resolved?
    When it is resolved, beause at this point the product has been changed. And it IS a CHANGE-log.

  • What format of changelog to use? Group by release or group by release and group by date?
    Group by release.

  • Should changlog be generated as html with hyper links to the actual bugs?
    Why not.

When this feature is finished I will celebrate a little party, because this is gonna save me a lot of time!

Thanks in advance!

Wanderer

Wanderer

2004-03-25 20:32

developer   ~0005266

  • Which bugs should be included in the changelog?
    I'll join to Ralfiii

  • When should a bug be included in the change log? When it is resolved? closed? or maybe when it is marked as tested (an example of a custom status).
    After <b>any</b> change in meaning "fixing"

  • What format of changelog to use? Group by release or group by release and group by date?
    By release, we measure nothing in days

  • Should changlog be generated as html with hyper links to the actual bugs?
    Can be

zorthar

zorthar

2004-03-29 04:11

reporter   ~0005279

IMHO, the format given with the mantis changelog is really great:

2004.02.29 - 0.18.2

  • Sec 0003595: bug_view_page.php: restricted custom fields are shown.
  • Enh 0003362: Generic email notifications.
  • Fix 0003077: Inconsistency: "Assigned To" versus "Handler".

Maybe that would need to add also a "Kind of Submission" field with the 3 enums:
Security, Enhancement, Bug Fix
in order to match the first field in each line of the changelog.

Luebbe

Luebbe

2004-03-29 07:36

reporter   ~0005282

Zorthar wrote:

Maybe that would need to add also a "Kind of Submission" field
with the 3 enums:
Security, Enhancement, Bug Fix
in order to match the first field in each line of the changelog.

I don't think so. This information could easily be gathered from the bug entries without using yet another table/custom field.

The current problem with mantis is, that there is IMO by default no clean separation of categories, issue types and priorities. When you look at your suggestion, you already see some confusion.

Security is a category (some might call it module) in your project
Enhancement & Bug Fix are general issue types (currently called severity in mantis).

So a valid line in the changelog would contain:
FIX #1234 - Security: some description
ENH 0006789 - Security: some other description

First column issue type (severity)
Second column issue ID
Third column category (module)
Fourth column description

Cheers
-Lübbe

thornsoft

thornsoft

2004-03-30 18:41

reporter   ~0005292

I've got a bolt-on that could be useful in the discussion, as a prototype.

http://www.thornsoft.com/mantis/bugfixlist.php?build=6.3.02.458

After building it, I realize that it would be more useful to have the cutoff be "equal to or EARLIER", when querying a particular release.

Chris

ralfiii

ralfiii

2004-03-31 03:03

reporter   ~0005294

I would like to see the "Product Version" field reused for the values of "fixed in version".

E.g. when you are working on version 1.16 of your software, possible values in "Product Version" would be ... 1.14, 1.15, 1.16(in development)

Most users would report bugs for version 1.15, if a deveoper fixes a bug he will most likely do this for Version 1.16beta (Exception: Reported used a very old verion and the bug has already been fixed in a previous version)

When version 1.16 is finished 1.16beta gets renamed to 1.16 (and 1.17beta is added). All fixed isses that previously had "fixed in V1.16beta" on it now state "fixed in V1.16". Voila!

I would not use a "normal" text field and let developers enter what they think here, because some might enter "V 1.16", some "1.16", some "16", so sorting would most likely fail most of the times. (This may not be true if you are only a 1-developer team)

brody

brody

2004-03-31 03:40

reporter   ~0005298

ralfiii,
I do not agree with you to reuse the product version field, because there will be bugs (or even more features), which get not resolved in the next or the actual working version and it seems to be interesting, in which version the bug has been found. I would like - as thornsoft shows - an additional field "FixInRelease", which must be administered as the products version field.

vboctor - are enumeration fields as custom fields possible?

vboctor

vboctor

2004-03-31 04:11

manager   ~0005299

I don't agree about re-using the product version field. Answering Brody's question: Yes, you can add custom fields that are enumerations. Checkout the manual (see the text around the light blue box):

http://manual.mantisbt.org/manual.customizing.mantis.custom.fields.php

We are considering adding a "Fixed in Released" field, but till then a custom field (enumeration) is the way to go. That is what we use currently in this Mantis installation.

redcom

redcom

2004-04-01 08:56

reporter   ~0005319

All - I dont think there is an aguement against it but I still will add more enthusiasm and say that I think this would be a great idea too.

thornsoft - can you upload that php file for everyone to use?

thornsoft

thornsoft

2004-04-02 16:17

reporter   ~0005330

Last edited: 2004-04-02 16:19

File uploaded as bugfixlist.zip . It needs to have the project on the parameter list, and I've got the filtering backwards - you probably really want to see the requested bug and EARLIER, not LATER. If I update it again, I'll probably do that, and maybe put in some breaks.

You'll see that I've hardcoded the path to my site (it was getting late!) and also field (3), which is my "fixed in release" field on the custom string table. Modify yours appropriately.

edited on: 04-02-04 16:19

Sire

Sire

2004-05-19 10:48

reporter   ~0005544

Mantis team, please add the thornsoft page in the next release (with suitable tweaks).

Thanks Thornsoft :)

vboctor

vboctor

2004-05-24 08:46

manager   ~0005573

I have just finished implementing 0003164. I will implement the Changelog feature based on the new native fixed_in_version field.

DGtlRift

DGtlRift

2004-07-28 15:39

reporter   ~0006422

Last edited: 2004-07-28 15:50

I think this goes beyond the scope of this issue and may need to be a new issue but in addition to the fixed_in_version field there should also be a fixed_in_build field, since we (and I'm sure others) fix bugs/issues in minor build patches.

However, this leeds to my next issue which is that when we go to a new version, we split the code (let's say version 3.0 (patch 14) to 4.0 (patch 0)) so that we can start including new features in the newer version. The issue arrises when a few months later an issue is found in version 3.0p15, and testers have found that it goes back to before the code split so it is also in version 4.0p2.

If version and fixed_in_version were dependancy keys on another table for a join, that could give the versions the issue was confirmed/fixed in.

In addition, the build (what we use to indicate patch-level) could also be used for this information if instead of being in the mantis_bug_table it was in a mantis_project_version_build_table that would be tied to mantis_project_version_table so that builds could be enumerated against versions.

edited on: 07-28-04 15:50

grangeway

grangeway

2004-07-28 17:36

reporter   ~0006424

Or just allow the changelog to be generic on a custom field rather then say, 'fixed in version' - this would allow a change log based on date, fixed in build, reported version, or anything someone could think up.

vboctor

vboctor

2004-07-28 19:04

manager   ~0006426

The current implementation already allows customising the following through the use of custom functions:

  1. Which issues should be included in the changelog (default issues with resolution fixed).
  2. The format for the included issues (which is currently the "- issue id: description (handler)"

So if you have custom fields you can use them. The only thing I am not sure about is whether I added the possibility of making the sections configurable (there is curretly a section per version). If this is required, then please report you request (and whatever snippets of our discussion here) into a new issue.

ralfiii

ralfiii

2004-07-29 02:11

reporter   ~0006434

From my point of view V0.19.0a2 already solves this issue.
Thanks vboctor for your great work!
(desparately awaiting a stable build for production use - any way to sponsor that?)

Wanderer

Wanderer

2004-07-29 07:24

developer   ~0006437

I'll join to DGtlRift in part of "Changelog for version and build". But I want see it form multi-level changelog. For me:
First level - Fixed in version
Nested - Fixed in build
will be excellent (we have public betas and ability to create automagilcally changelog for each beta insted current date filtering will be good add-on and it'll have sense not only for me)!

vboctor

vboctor

2004-07-29 23:32

manager   ~0006470

ralfiii, 0003987 tracks what is planned for 0.19.0, you can sponsor that. However, you can also sponsor specific issues on the list which would be even better.

DGtlRift, please report the multi-level changelog as a separate issue. However, I am not currently expecting it to be part of 0.19.0. But you never know. If you are too keen, you can always sponsor it.

DGtlRift

DGtlRift

2004-07-30 08:09

reporter   ~0006475

Added issue http://bugs.mantisbt.org/bug_view_page.php?bug_id=0004218 explaining schema and idea of multilevel ChangeLog