Scala 2.13 cross-build upgrade

[dmitry-worker]

Scala 2.13 port of scalanet is a blocker to Mantis backlog task.

A library can be built now against both - 2.12 and 2.13 targets.
Further advice is needed regarding documentation and publishment.

[aakoshh]

Thank you for figuring out the cross build, good job!

Are all commands the same, does it automatically publish both versions?

[aakoshh]

Suggested change

	override def publishVersion = "0.5.0-SNAPSHOT"
	override def publishVersion = "0.5.1-SNAPSHOT"

It's a bit of a pain but once we start using a version in a project which uses Nix expressions we have to increment the version here otherwise all builds in those projects will constantly break down because of hash changes. Konrad is already migrating to 0.5.0 so we should bump it.

I guess this will be difficult to coordinate, so we should have explicit release process which removes the -SNAPSHOT, and projects that do want to compile against SNAPSHOT should deal with the Nix expressions. @KonradStaniec how do you do releases?

[dmitry-worker]

0.5.1 is now officially set 🥇

[KonradStaniec]

@aakoshh to this time i have only done release one time so the process is a bit ad hoc and manual:

1. create release branch
2. create commit which removes -SNAPHOST version, and add necessary modification to build.sc (last time I needed to modify it add myslef do developers field to by able to do realease). In general we do not have mill version, and thigs change based on mill version, which breaks things pretty often. (maybe we should fix mill version to make it easier, wdyt ?)
3. tag this commit
4. run mill incantation i.e the same thing which is running when merging to develop, but with --relase flag

[aakoshh]

I see we have a master branch as well. Would it be enough to merge develop into master, update the version there, then tag it, and add a pipeline step that publishes with --release if the tag looks like a semver? As it's described in the Gitflow workflow I'd only use release branches as a short lived branch where any remaining bugs are sorted out before it's merged into master and develop, then get rid of them. That would avoid changes lingering there forever, not making it into the next release, etc, and also any ambiguity of whether a specific version should be looked for as a branch or as a tag.

[aakoshh]

I also used to have build.sbt take the version from the git tag, if it looked like a semver, so we don't have to remove the SNAPSHOT and then add it back when the master or the release is merged back into develop.

[dmitry-worker]

Thank you for figuring out the cross build, good job!

Thanks :) I hope my effort will make this project even better.

Are all commands the same, does it automatically publish both versions?

No, the pull request is still draft, hope I can finish the work in 2-3 days.
Documentation update is not ready as well

[aakoshh]

I wonder why we don't have any build show up in https://app.circleci.com/pipelines/github/input-output-hk/scalanet

Can't remember if it happens for draft PRs. Maybe you have to be part of some group to have your commits trigger builds?

[dmitry-worker]

Closed in favor of #113