Switch from generating scala.collection.Seq to scala.collection.immutable.Seq

[smarter]

No effect on 2.12, but on 2.13 this is what should be preferred and
makes the most sense since we're dealing with immutable values.

[eed3si9n]

sbt-buildinfo has been using scala.collection.Seq since 2016 (#81) long before the Scala 2.13 migration happened, and given that the generated code might be part of someone else's API, the fact that it's scala.collection.Seq and not scala.Seq is a happy coincidence that would allow building without changing the semantics between the cross-Scala builds.

scala.collection.Seq is the first option we recommend in the migration guide as well.

[smarter]

But scala.Seq (or scala.collection.immutable.Seq if you prefer) is really what you want for immutable things, and what you want by default (after all, that's the whole reason why scala.Seq is now scala.collection.immutable.Seq, because it's a better default).

scala.collection.Seq is the first option we recommend in the migration guide as well.

I don't think that switching a codebase to scala.collection.Seq is realistic, it's fine in a few cases, but to use it consistently in a codebase requires a huge refactoring and means fighting against the spirit of 2.13 (varargs, every library you're using which uses scala.Seq, ...).

On the other hand, when moving from 2.12 to 2.13, I didn't have to do that many changes in my code, but I had to add a few .toSeq for values coming from sbt-buildinfo, this wastes CPU resources for no reason.

[eed3si9n]

What do you think about using concrete datatypes like Vector instead so it would be immutable for both pre-2.13 and 2.13+?

[smarter]

That's also fine

[smarter]

I switched to scala.collection.immutable.Seq since that seems like the most natural choice, but happy to replace that with Vector if you prefer.