> But for new features, it is different. The CHANGES entry is only added to > the first version the feature was introduced (e.g. 7.0.0), even if the > feature is committed to master, branch_7x, branch_7_0. In my head it would > make sense to tag it as Fix-Version=7.0.0 and not also 7.1 and 8.0.
I don't think it's that much different, really. If you introduce a feature on branch_7x and apply it to master then it's both on branch_7x and master. Let's say somebody then cuts out branch_8x from master and creates a release of version 8.0. Then that somebody should tag patches on current master with branch_8x and 8.0 (assuming he's immediately going for the release). And then you'd see this on your feature issue's fix-for: branch_7x, branch_8x, 8.0, master and since branch_7x hasn't been released yet, the feature would be introduced in version 8.0, not any tagged version on 7x (because they haven't been released yet). You could either rollback that feature from branch_7x (and remove the tag), or keep it and release that feature from both branches (next version of 7x). Or never release branch_7x at all, but keep the patch there anyway. Sure, this is a bit abnormal to have the same new "feature" on two different branches, but you can apply the same thinking to bugfix versions as well (features or any kind of patch). This is something Hoss mentioned -- when you're doing multiple parallel releases of versions from different branches it becomes a headache quickly to figure out which version carries a certain patch (whether it's a bug, feature or whatever else). But in reality it is often the case (in my personal experience) that multiple versions do carry the same set of patches, be it bug fixes, refactorings or even new features and those tags in jira help to figure out where a given patch exists. Dawid --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
