Hi Team, Often we consider some issue need to be merged to one of the branch but it is not immediately required. For e.g. a practice we have recently started is to have some new feature implemented in trunk and then have it enabled by default there. Once we find it to be stable we enable it by default in branches. For such work I typically create 2 issues, A (e.g. OAK-3069) for actual work and B (e.g. OAK-3073) for tracking making it enabled by default.
Now #B has to be marked resolved in trunk but I have to keep a mental note that this needs to be done in branch also sometime later. This approach is error prone. Instead if we make use of labels to mark issues which are suitable _candidates_ for merge to branches then we can track such issues via JIRA query and revisit them when we cut new releases on branch. I propose we use following labels candidate_oak_1_0 candidate_oak_1_2 For issues to be merged to 1.0 and 1.2 branches. Then later we can query for such issues. Thoughts? Chetan Mehrotra
