Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Typelevel migration logistics #490

Open
rossabaker opened this issue Aug 3, 2019 · 23 comments

Comments

@rossabaker
Copy link
Member

commented Aug 3, 2019

@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

This comment has been minimized.

Copy link
Contributor

commented Aug 3, 2019

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: #423 (comment) (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

This comment has been minimized.

Copy link
Member Author

commented Aug 3, 2019

Yes, thank you. Version numbers corrected above.

@kailuowang

This comment has been minimized.

Copy link
Member

commented Aug 4, 2019

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

This comment has been minimized.

Copy link
Member

commented Aug 4, 2019

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

This comment has been minimized.

Copy link
Member Author

commented Aug 4, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Aug 4, 2019

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

This comment has been minimized.

Copy link
Member

commented Aug 7, 2019

@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

This comment has been minimized.

Copy link
Member

commented Aug 7, 2019

@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

This comment has been minimized.

Copy link
Member

commented Aug 7, 2019

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

This comment has been minimized.

Copy link
Member

commented Aug 7, 2019

@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

This comment has been minimized.

Copy link
Member

commented Aug 7, 2019

@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

This comment has been minimized.

Copy link
Member

commented Aug 7, 2019

Perfect, thanks @djspiewak!

@smarter

This comment has been minimized.

Copy link
Contributor

commented Aug 7, 2019

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

This comment has been minimized.

Copy link
Collaborator

commented Aug 7, 2019

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

@non

This comment has been minimized.

Copy link
Member

commented Aug 7, 2019

@smarter Agreed.

@SethTisue

This comment has been minimized.

Copy link
Collaborator

commented Aug 7, 2019

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

@dwijnand

This comment has been minimized.

Copy link
Contributor

commented Aug 8, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Aug 8, 2019

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

This comment has been minimized.

Copy link
Collaborator

commented Aug 8, 2019

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

This comment has been minimized.

Copy link
Member

commented Aug 8, 2019

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

This comment has been minimized.

Copy link
Member

commented Aug 8, 2019

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

@sjrd

This comment has been minimized.

Copy link
Contributor

commented Aug 8, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Aug 9, 2019

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

I've implemented this proposal in #498 where it's currently being discussed, people with opinions on source/binary compatibility may want to weight in.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
10 participants
You can’t perform that action at this time.