With Scrum you can try to plan longer releases using team velocity. If
team velocity is 100 Story Points (SP)/Sprint and the Product Backlog
has 1000 SP then you can say you can finish in 10 Sprints.
Theoretically, yes. In the real world, though, if you can have your scope of work so well-defined, why are you using iterative and incremental methodologies? Frameworks and methods like Scrum are best suited to cases with higher amounts of uncertainty and ambiguity, which prevent this kind of long-term planning and commitment.
When developing software with Kanban it doesn't have velocity. How can
you plan releases with Kanban?
Like with Scrum, I'd assert that methods and practices like Kanban are best suited to environments where long-term planning and commitment aren't viable. Release planning is primarily around organizing the work so the most important work happens first and using other techniques to release usable increments as frequently as possible.
I see cycle time and lead time used often. Is it with these? I assume
tasks must all be the same otherwise how can you use these KPIs? If
one story is 2 SP and one is 8 SP, Scrum adds them up, but in Kanban
their times will differ. Do you average?
In addition to cycle time and lead time, you can also consider throughput. If you know these metrics along with the size of the work, you can forecast when a given piece of work will likely be done based on where it is in the backlog. As you shuffle the backlog, you can use these same metrics to determine what impacts those have on particular units of work getting to the top of the backlog and then from the top of the backlog to a done state.
There's also nothing that is stopping you from using cycle time, lead time, and throughput with Scrum, as well. Scrum.org has built the Kanban Guide for Scrum Teams to help incorporate traditional Kanban tools and techniques into the Scrum framework to support Scrum's roles, events, and artifacts.