Typelevel migration logistics

[rossabaker]

@non says:

So talking to @rickynils, it sounds like he plans to move the project to Typelevel, as per the suggestions of @SethTisue et al.

At that point, if we fix up the build to support sbt-release etc. we should be able to cut a new release ASAP (published to org.typelevel instead of org.scalacheck).

@ashawley has done a nice job scoping tickets in #453, but I want to discuss logistics of it. The ecosystem's move from scalacheck-1.13 to 1.14 is still incomplete. It is the primary driver for cats-2 and major versions of everything downstream, and I want to be careful that we don't trigger yet another epoch.

If the project starts publishing to Sonatype under org.typelevel, we will not get eviction notices on things that transitively depend on current releases of scalacheck. This will result in Class Loader Roulette. We could mitigate this by moving the code to package org.typelevel.scalacheck and providing a scalafix. If we're going this route, we should do this before cats-2.0, which means ASAP. Scalatest-Plus insulates ScalaTest, but this would also have fallout on Specs2 and Discipline, among others.

We could keep publishing under org.scalacheck, even if we moved the project under the Typelevel GitHub org. We could then keep the version at 0.14 1.14 and let downstream proceed with current plans, but we'd want to get a handful more developers with Sonatype access to org.scalacheck, which is a solved problem if we republish under org.typelevel.

Because of this project's critical position in the ecosystem, if we do make any breaking changes, it would be nice to call it 1.0 2.0 and then be extremely conservative about breaking changes.

This only hurts because the project is so good. Thanks to all who got us here.

[smarter]

f we do make any breaking changes, it would be nice to call it 1.0

Do you mean 2.0 ? The current version is 1.14.0.

Speaking of breaking changes, compiling scalacheck using Dotty will require exactly one source-breaking (but not binary-breaking) change: https://github.com/rickynils/scalacheck/pull/423#issuecomment-509687959 (unless someone can think of a way to avoid it), a good way to mitigate the impact of that change would be to deprecate BooleanOperators as soon as possible (so, in 1.14.1).

[rossabaker]

Yes, thank you. Version numbers corrected above.

[kailuowang]

It seems to me that giving a couple of more developers the publish right under org.scalacheck is easier overall. It's weird sonatype jira ritual, but still easier than forcing the whole community to migrate. Just need to comment on this jira issue Also given there is already the domain name, it makes more sense to continue publish under that org.
I guess we just need to gather a list of typelevel developers interested in helping. (I raise my hand)

[non]

At this point I have the ability to publish to org.scalacheck so the biggest thing is to refactor the build into a more modern form where anyone can release it using sbt-release + sbt-sonatype (in its current form I think it requires @rickynils to do it).

I'm going to start working on that now, since the work won't be wasted no matter what we end up doing.

[rossabaker]

I agree with keeping publishing under org.scalacheck with an improved bus factor is the best option.

I often forget that scalacheck is 1.x because the last minor version was a major version in disguise. We shouldn't fear an eventual 1.15, 1.16, etc., as long as it's semantically versioned. MiMa enforcement as an sbt-release step would be another good safety measure.

[dwijnand]

Thanks @rossabaker for bringing up the eviction/classpath implication of moving groupIds.

@non feel free to ping if you need help (in both informational or legwork capacity) with those build/release changes.

[non]

@dwijnand So I'm working on this now. The one question I have -- using sbt-release, is there a good way to cross build for two versions of ScalaJS?

Right now there's a fiddly process using environment variables to interpolate two different versions (both 1.0.0-M8 and 0.6.28) and I'd really prefer to set things up so a single release command will publish the matrix of all Scala/ScalaJS versions (as well as handling the Sonatype stuff).

What do you think? Is there a better way to do this?

[djspiewak]

@non Can you do me a favor and 👍 my Sonatype access request? (https://issues.sonatype.org/browse/OSSRH-3308) Given the slightly unusual nature of what I'm noting, it might be best of @rickynils also weighs in, though I understand he's quite busy.

[djspiewak]

Also, @non, if it helps I've always found sbt-release to be too fiddly and really not actually all that helpful. I usually do something like this instead, so that's another option if you want it.

[non]

@djspiewak I'm happy to give a 👍 but in the short term please coordinate with me before releasing anything -- I'm current planning to try to do a partial release to address #496 tonight and am cleaning up the build (and merging PRs) in advance of a new release.

[djspiewak]

@non Oh I'm not going to release anything without your go-ahead! :-) I mostly just wanted to get the ball rolling on removing the bus factor, and as someone who doesn't really mind most of Sonatype's ritual dances, I seemed the logical choice to get that particular item off your plate.

[non]

Perfect, thanks @djspiewak!

[smarter]

Now that the repo has been moved to typelevel/, I'd like to recommend that @ashawley be given admin rights to the repo, he's been active in the scalacheck repo for a while (reviewing PRs, responding to issues, ...) and he's known in the community as the maintainer of https://github.com/scala/scala-xml.

[rickynils]

@smarter @non I have no objections on making @ashawley a maintainer. He has done a lot of work on scalacheck.

[non]

@smarter Agreed.

[SethTisue]

nomination of @ashawley seconded, he's been a responsible steward of scala-xml (and done good stuff elsewhere in Scala OSS land, too)

[dwijnand]

is there a good way to cross build for two versions of ScalaJS?

I've not maintained any builds cross-building for Scala.js, so cc'ing @sjrd.

[sjrd]

The way it's based on an environment variable for the version of Scala.js to load as sbt plugin. It's explained in the release notes of 1.x milestones, but the website is down right now because of the service provider. You can see how it's done in https://github.com/portable-scala/portable-scala-reflect for example, which is the simplest cross-compiling project I know.

[ashawley]

Thanks for the nomination. I'm happy to continue helping out here, and glad to hear that ScalaCheck will benefit from the Typelevel organization going forward. Hopefully, we make Rickard proud and emulate his many years of ScalaCheck maintenance going forward.

[djspiewak]

Upgraded @ashawley's permissions on this repo to Admin per all of the above. Woot!

Hopefully, we make Rickard proud and emulate his many years of ScalaCheck maintenance going forward.

Hear, hear.

[non]

@sjrd This is very helpful, thanks! What sort of release process do you all use for that repo?

[sjrd]

The same I use for all my repos:

1. Create a commit where I change the version number to non-snapshot
2. Have the CI run through a PR
3. Fast forward the commit to master, tag it
4. In an ideal world, the tagging takes care of publishing from the CI, but I've never set that up so I manually publish
5. Create another commit that resets the version number to the next snapshot

The process can also work with a tag-only based publishing similar to what is used in Scala module repos, which allows to remove steps 1 and 5.

[smarter]

Speaking of breaking changes, compiling scalacheck using Dotty will require exactly one source-breaking [...]

I've implemented this proposal in https://github.com/typelevel/scalacheck/pull/498 where it's currently being discussed, people with opinions on source/binary compatibility may want to weight in.

[SethTisue]

Closing since it's unclear if there's anything left to discuss. If there is, please open new, more specific tickets.

(I believe Daniel remains a skeptic about switching to sbt-ci-release.)