Release Plan . Part of Scrum ?
Page 16 of scrum guide states
Monitoring Progress Toward Goals At any point in time, the total work remaining to reach a goal can be summed. The Product Owner tracks this total work remaining at least every Sprint Review. The Product Owner compares this amount with work remaining at previous Sprint Reviews to assess progress toward completing projected work by the desired time for the goal. This information is made transparent to all stakeholders.
Various projective practices upon trending have been used to forecast progress, like burndowns, burn-ups, or cumulative flows. These have proven useful. However, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision-making
I would definitely call this a release plan. I understand that each increment is a potentially releasable unit however, everyplace I have been involved the stake holders demand when certain functionality will be released for production. AKA - Release Plan
You might call it a Release Plan, sure. A better term would be "release forecast" though. Because all you do is extrapolate when something will be done based on data from the past and present that is subject to change. Both the Product Backlog and the rate of the team's progress will change (not "might" - "will"), so the forecast is weak and gets weaker the further into the future it goes. It is not a commitment and everyone involved needs to understand that.
For specific features, a Product Owner may articulate such a forecast as a likely date plus or minus a number of days to a given level of certainty.
A simpler forecast might just use the current position and size of items in the backlog and the established velocity.
One for the myths related to Scrum is that we can't do project planning. As mention in the previous comment, using the velocity of the team and the remaining of the backlog items, one can forecast the project end. This re-planning would be done per sprint (here is where the empirical process kicks in...).
One note of reality: your initial plan won't be accurate, not matter how hard you would try. Even if the velocity is stable the unknown unknowns will shift your dates. So this is project forecast rather then project commitment. If you need to commit for long project (agile in waterfall organization) make sure to take some buffers, either on content or on time.