... | ... | @@ -160,4 +160,14 @@ There's the scenario: Someone reports a problem, we look at it, come up with a s |
|
|
|
|
|
There may be other reasons. In all cases the major point is that the original problem remains unsolved and there is more to be done here. What should be done in such cases? **You can only close a ticket once**. If there's a reopen, a third person needs to get involved and independently confirm that the solution is valid and complete. This is kind of natural extension of the process we have for review where if dev and reviewer cannot reach an agreement, they ask for a third opinion. Feel free to ask the third person depending on the situation - a dev that's expert in the area, maybe someone from QA or get a manager involved.
|
|
|
|
|
|
In any case, closing a ticket that was reopened can easily be considered as rude behavior and can damage the public image of the whole project. If there's really nothing reasonable to be done in the short term, perhaps moving to %Outstanding is a good alternative to closing? |
|
|
\ No newline at end of file |
|
|
In any case, closing a ticket that was reopened can easily be considered as rude behavior and can damage the public image of the whole project. If there's really nothing reasonable to be done in the short term, perhaps moving to %Outstanding is a good alternative to closing?
|
|
|
|
|
|
# Bump lib version for development or release version
|
|
|
|
|
|
The safest way to bump lib version for newer development or release version is:
|
|
|
- if the library has not changed at all, leave version info untouched
|
|
|
- if any change has been made to the library source code, bump 'current' and set 'revision' and 'age' to 0
|
|
|
|
|
|
This will guarantee that the new library needs to be recompiled in order to be used by older or newer versions of the binary.
|
|
|
|
|
|
This can also be automate the process by the release procedure. |
|
|
\ No newline at end of file |