Backporting of fixed bugs

[daniel.soneira]

I wonder how you handle incorporating bug fixes (in 3.2 trunk) which also would benefit the older branch (3.1)?

My favorite bug of all time (RF-997) (god I hate that thing) has not been fixed in the version that it was meant to be.

Do you evaluate the merging after fixing EVERY bug or does one person (like Nick) watch over all recently fixed bugs and decides which get backported?

Do we as users have to file new issues if we think a bug may apply for the older version too? Does SOMEONE get notified if I add a comment to a "closed" JIRA issue at all? - I don't want to make a new thread every time just for an issue to be looked at again.

[ilya_shaikovsky]

First question. After the bug resolved in trunnk we've checking if the changes was minor, unharmfull and without compatibility breaks. If so - we've merge the bug into 3.1.x.
In every 3.1.x new version we've make this more and more carefully because differences between branches becames bigger.

So in 3.1.6 for example we planing to fix about 5-10 bugs only. We can't fix every one bug in order not to loose 3.1.x version stability.

Your favourite bug has 3.2.0 fix version only because renderer for calendar was influenced with a fix too much.

"Do we as users have to file new issues if we think a bug may apply for the older version too?"

Your votes is importan for us.

"Does SOMEONE get notified if I add a comment to a "closed" JIRA issue at all?"

Yes. But look to our jira it has already about 3000 bugs.. So sometimes notifications can be lost.

"I don't want to make a new thread every time just for an issue to be looked at again."

But in this case you'll sure that we've read this ;)

[daniel.soneira]

Thanks for the info. I understand there are quite some problems in managing different branches as time goes by.

I disagree on the handling of RF-997 not being merged though - the last patch is only some lines of code that needed to be changed - I manually merged it onto the 3.1.5 version without problems (see changes for revision #7056). The other two commits were already part of 3.1.x branch - there was no 3.2 at that time :)

Do you create a brand new issue for the merging or do you create subtasks in the original issue?

Your votes is importan for us.

- so, you want me to file a new issue, or vote on the closed one?

I have no problem in creating forum threads - it just might be kind of annoying for you RF-developers. If that's not the case, good :]

But look to our jira it has already about 3000 bugs..

That's why we voted for stability - let's fix 'em one by one :)

Good luck and thanks for your endeavors .