> For the complete documentation index, see [llms.txt](https://docs.eximee.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.eximee.com/documentation/documentation-en/budowanie-aplikacji/aplikacja-biznesowa/dokumentowanie-aplikacji/formatowanie-i-najlepsze-praktyki-tworzenia-changelogu.md).

# Formatting and best practices for creating a changelog

The changelog is a summary of changes introduced in the application together with their business description. The main goal is to maintain a clear history of the application's development, arranged in chronological order (from newest) and grouped into packages. The way to add the changelog to the application is described in: [Application documentation](/documentation/documentation-en/budowanie-aplikacji/aplikacja-biznesowa/dokumentowanie-aplikacji.md).

## Syntax and formatting

The changelog should be written in a unified and consistent structure and format based on headings and lists (entries are created using the [Markdown](https://www.markdownguide.org/basic-syntax/)).

Changelog structure:

{% stepper %}
{% step %}
H1 heading (#)

* Changelog title.
* Placed only once at the beginning of the file.
  {% endstep %}

{% step %}
H2 heading (##)

* Package name.
* It should include the application name and the package send date.
* Each package is a separate heading.
* Packages should be saved from newest to oldest (newest at the top).
  {% endstep %}

{% step %}
H3 heading (###)

* Entry category.
* Within one package, several category headings can be added (the categories are listed further below).
  {% endstep %}

{% step %}
Single change entry

* Placed as a bulleted list under the appropriate category.
* The syntax of a single entry should look as follows:

  * \[Jira number]\(Jira link)\[customer Jira number]\(customer Jira link)\* Change description \[name of changed artifact(s) and its/their version after the change]

  \*The customer Jira number and link are optional, but it is worth adding them if the change is a response to a customer report.

<figure><img src="/files/c3469f951e4e8dad683c6a379a761028d46d3c90" alt=""><figcaption><p><em><strong>Figure 1.</strong> Example fragment of the changelog in the edit window</em></p></figcaption></figure>
{% endstep %}
{% endstepper %}

## Entry categories

* New functionalities - new elements or functions in the application,
* Modifications - changes in existing functionalities,
* Fixes - entries concerning the resolution of reported bugs,
* Configuration - entries with information about configuration parameters.

## Entry language and best practices

A good practice is to use business language and avoid technical details, i.e. describe the change in terms of value for the user. Example: "Fix in the amount formatter" can be described as "Improved loan amount formatting".

Before sending the package, remember to update the send date in the changelog. Example: ALXXXXXXXX - XXXX-XX-XX → AL20250101 - 2025-01-01 (format YYYY-MM-DD).

The changelog sent to the customer should reflect the actual state of the package as closely as possible. It should include all entries related to added functionalities, modifications, or fixes.

## Example changelog template

Below is an example of the structure and an example entry. Keep the formatting and links.

{% code expandable="true" %}

```markdown
# Changelog for the 300plus application
<!--
## EXIMEEYYYYMMDD_300PLUS_APP - YYYY-MM-DD
 
### New functionalities
- 1
- 2
 
### Modifications
- 1
- 2
 
### Fixes
- 1
- 2
-->
 
## EXIMEE20250901_300PLUS_APP - 2025-09-01
 
### Fixes
- [EXIMEE-1234](https://jira.consdata.pl/browse/EXIMEE-1234) Example change description [artifact: 300plus 1.02]
```

{% endcode %}

(The example above serves only as a template — in practice, record the list of packages and entries from newest to oldest, following the described rules.)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.eximee.com/documentation/documentation-en/budowanie-aplikacji/aplikacja-biznesowa/dokumentowanie-aplikacji/formatowanie-i-najlepsze-praktyki-tworzenia-changelogu.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.