MySQL++

Changes To FAQ
Login

Changes To FAQ

Changes to "FAQ" between 2017-07-05 00:10:27 and 2017-09-08 19:06:06

195
196
197
198
199
200
201
202



203
204
205
206
207

208
209
210
211
195
196
197
198
199
200
201

202
203
204
205
206
207
208

209
210
211
212
213







-
+
+
+




-
+






## <a name="bugreport"></a>I’m sure I’ve found a bug. How do I submit a report?

We’ll want some code that demonstrates the bug. No doubt you’d rather not send us a copy of your database to demonstrate the problem, and to be frank, we don’t want your database, either. The best thing is to modify one of the MySQL++ examples so that it reproduces the problem you’re seeing. This lets the people that can help you reproduce the problem on their machines, without needing your database.

Once you have your problem boiled down to a simple example, send the source code to the mailing list 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 programs.
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 mailing list 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 `HACKERS.txt` file](/doc/trunk/HACKERS.txt).
This is covered in detail in the library's [hacker's guide](/doc/trunk/HACKERS.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 [mailing list](http://lists.mysql.com/plusplus/), 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.