I thought some context on how this whole thing works might help. A little insight into the development of this project might make some of my development decisions clearer. (If not correct.) So welcome to the secrets of TinyXml development!
TinyXml development is ad-hoc. We seem to go for about 3 months and don't work on the code, and then either I or Yves get a move on and write some code. Usually to fix either a problem I'm having, or because someone has submitted a really compelling idea. Or, in a few cases, there are bugs I've wanted to fix for a long time and enough bug reports have come in to move me to action. I like working on TinyXml, to be clear, but I am busy with many things.
In any case, after the 3-month lull, I'll work on it for a couple of months for an hour or two a week, with a couple weekend-days thrown in for good measure. If someone else is working on the code, they generally stick with for a month or 2 or 3 until their issue is integrated or resolved. Generally then, they move on, having got out of the library the changes they needed. That used to bother me, but not any more. Now I see it as a very natural way to contribute to a project like this. Those 1-3 month contributions have enriched TinyXml immeasurably.
With every feature, or bug, I add test cases to xmltest.cpp to try to guarentee features work and bugs are fixed and don't re-appear. I compile on Windows MSVC 6 & Dev-C++, and on Linux using gcc 3 on Red Hat Linux. I build all 4 configurations (debug/release, and STL on/off) and test them on Linux and Windows before release.
What does this mean?
** 1. Bug reports are really important. **
Bugs submitted through the SourceForge bug reporting system can be tracked. In some cases, over years. Some bugs are fixed sooner, some longer. But they don't get lost there! Bugs submitted via email can get lost, or other developers don't see them.
2. Feature requests through sourceforge - same issue. They don't get lost. Correctly filing a "bug" vs a "feature" helps greatly, by the way.
3. Time is of the essence. This is the critical one - it takes me about an hour to release the code. For some weeks, that's all I have...so I always push back on anything that makes release more complex.
4. Simplicity is important. I only development TinyXml on 2 platforms, and rely on the greater community for bug feedback. But TinyXml is deployed on...everything. CE, Palm, Workstations, Devices, OSX, on and on. Also, the users of the project range from very sophisticated programmers to newbies, which is great. I want it to be useful and accessible to the largest possible range.
So that's how it works! I hope you enjoyed this look into the Development Secrets of TinyXml!
lee
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I thought some context on how this whole thing works might help. A little insight into the development of this project might make some of my development decisions clearer. (If not correct.) So welcome to the secrets of TinyXml development!
TinyXml development is ad-hoc. We seem to go for about 3 months and don't work on the code, and then either I or Yves get a move on and write some code. Usually to fix either a problem I'm having, or because someone has submitted a really compelling idea. Or, in a few cases, there are bugs I've wanted to fix for a long time and enough bug reports have come in to move me to action. I like working on TinyXml, to be clear, but I am busy with many things.
In any case, after the 3-month lull, I'll work on it for a couple of months for an hour or two a week, with a couple weekend-days thrown in for good measure. If someone else is working on the code, they generally stick with for a month or 2 or 3 until their issue is integrated or resolved. Generally then, they move on, having got out of the library the changes they needed. That used to bother me, but not any more. Now I see it as a very natural way to contribute to a project like this. Those 1-3 month contributions have enriched TinyXml immeasurably.
With every feature, or bug, I add test cases to xmltest.cpp to try to guarentee features work and bugs are fixed and don't re-appear. I compile on Windows MSVC 6 & Dev-C++, and on Linux using gcc 3 on Red Hat Linux. I build all 4 configurations (debug/release, and STL on/off) and test them on Linux and Windows before release.
What does this mean?
** 1. Bug reports are really important. **
Bugs submitted through the SourceForge bug reporting system can be tracked. In some cases, over years. Some bugs are fixed sooner, some longer. But they don't get lost there! Bugs submitted via email can get lost, or other developers don't see them.
2. Feature requests through sourceforge - same issue. They don't get lost. Correctly filing a "bug" vs a "feature" helps greatly, by the way.
3. Time is of the essence. This is the critical one - it takes me about an hour to release the code. For some weeks, that's all I have...so I always push back on anything that makes release more complex.
4. Simplicity is important. I only development TinyXml on 2 platforms, and rely on the greater community for bug feedback. But TinyXml is deployed on...everything. CE, Palm, Workstations, Devices, OSX, on and on. Also, the users of the project range from very sophisticated programmers to newbies, which is great. I want it to be useful and accessible to the largest possible range.
So that's how it works! I hope you enjoyed this look into the Development Secrets of TinyXml!
lee