There is a very frustrating situation when capacity planning done in the beginning of the release can not be persisted by the end of the release when you have undelivered features and have to move them to another release. This breaks the capacity allocation and tracking/review capability. Splitting the feature thus is the only option and it is not always a preferred choice.
I would like to propose a new complexity of the relationship between releases and features by implementing N:N relationship with ability to persist time tracking attributes on particular relation, also, quite importantly, other attributes - status, assignee.
One of the many implications - features will have ability to be planned within multiple releases.
One of the perspectives for grooming - "versioning of the feature". It would be interesting to combine it with "master feature".
P.S. relases are really just time-frames. Prior execution, they represent "a plan", during execution they represent "what is worked on" and when the release window ends, they represent "what is delivered". Each of those 3 categories might be represented by not always the same features. Especially first and last one.
Thank you for your idea. Master features can span multiple releases in that the features they contain can be from multiple releases. In a situation where you have a feature that includes work across multiple releases, we would recommend using master features to represent the larger feature to deliver. You can then create separate features representing the work to be done in each release -- all related to the main master feature.
Given the availability of master features, we do not have plans to allow a feature to span multiple releases. We hope you can understand.