Once you have your problem boiled down to a simple example, send the source code to the [forum] along with a detailed report. We want to know what you expect the program to do, and what it actually does on your machine. Keep in mind, programs often behave differently on different systems. As a programmer yourself, you know what it is like to deal with vague user bug reports. Give us the sort of error report you’d like to receive for your own programs.

There's also the [ticket tracker](/ticket), but we prefer that you send the report to the [forum] for discussion first. Especially do not use the ticket tracker if you just need help *using* MySQL++.


## <a name="patches"></a>How do I submit a change to MySQL++?

This is covered in detail in the library's [hacker's guide](/doc/trunk/HACKERS.md).
This is covered in detail in the library's [contribution guide](/doc/trunk/CONTRIBUTING.md).

But in brief: we want the patch in unified diff format, made against either the latest release of MySQL++ or (preferably) against [the trunk of the Fossil repository](/timeline?r=trunk). You can send it either to the [forum] or to [the ticket tracker](/ticket). We prefer that you only use the ticket tracker for patches that are so trivial or obvious that they won’t need discussion.

When a patch is rejected, the most common reason is that it breaks the library’s binary interface (ABI), so that an old program can’t link to the changed library without recompiling. We only make such changes at major version transitions. These transitions are rare, and we can’t even promise that there will ever be another one, much less when it will occur. If you have a choice of two ways to get your desired effect and one of them doesn’t break the ABI, it will increase the chances that we accept your patch if you do it that way.

<p style="height: 50em">&nbsp;</p>