|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
We haven't lost the advantage of multiple branch workflows with the current implementation of the plugin. A build launches for each branch which has changes detected. I don't think we've lost the advantage of various git branching models by showing the build status for each execution of the job. It is consistent with other Jenkins jobs and with other plugins.
Your proposal changes the meaning of build status, and I suspect there are many locations which assume the current meaning of build status, rather than your more sophisticated proposal.
Considering how sensitive I am to compatibility, I suspect I would not accept such a change without deep confirmation that compatibility had not been broken by the change, and that memory use had not increased dramatically with the feature enabled.