View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0003638 | mantisbt | feature | public | 2004-03-05 08:47 | 2004-09-12 08:27 |
Reporter | ale | Assigned To | vboctor | ||
Priority | normal | Severity | feature | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Fixed in Version | 0.19.0a1 | ||||
Summary | 0003638: 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... | ||||
Tags | No tags attached. | ||||
Attached Files | |||||
related to | 0004218 | new | Issue found/fixed & version/build relationships with Changelog |
I think this is a useful feature, however it requires a lot of thought:
However, I think it is to be generated on request, and not stored in a table. |
|
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:
When this feature is finished I will celebrate a little party, because this is gonna save me a lot of time! Thanks in advance! |
|
|
|
IMHO, the format given with the mantis changelog is really great: 2004.02.29 - 0.18.2
Maybe that would need to add also a "Kind of Submission" field with the 3 enums: |
|
Zorthar wrote:
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 So a valid line in the changelog would contain: First column issue type (severity) Cheers |
|
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 |
|
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) |
|
ralfiii, vboctor - are enumeration fields as custom fields possible? |
|
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. |
|
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? |
|
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 |
|
Mantis team, please add the thornsoft page in the next release (with suitable tweaks). Thanks Thornsoft :) |
|
I have just finished implementing 0003164. I will implement the Changelog feature based on the new native fixed_in_version field. |
|
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 |
|
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. |
|
The current implementation already allows customising the following through the use of custom functions:
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. |
|
From my point of view V0.19.0a2 already solves this issue. |
|
I'll join to DGtlRift in part of "Changelog for version and build". But I want see it form multi-level changelog. For me: |
|
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. |
|
Added issue http://bugs.mantisbt.org/bug_view_page.php?bug_id=0004218 explaining schema and idea of multilevel ChangeLog |
|