Plan next release

@hvesalai

A lot of PRs have now been merged since 3.3.3.

I was thinking we might do 3.4.0-RC1 first, then 3.4.0? That's just a suggestion; @hvesalai and @nafg, you can handle this as you see fit. I can help pull publishing levers when the time comes. (I have no opinion about timing.)

One question that came up over at #1496 is binary compatibility. I enabled MiMa in the repo with the idea that at minimum, we would probably like to be notified by CI when something isn't binary compatible.

I have no position on whether the next version should be binary compatible or not. By semantic versioning (which I do suggest we follow), a 3.4.0 version should be backwards binary compatible. But if we call it 4.0.0 instead, then we're completely free to break bincompat.

Anyone know what the policy has been until now?

We've followed the semantic versioning, i.e. kept thing binary compatible between minor versions.

Here's the specification for scala https://docs.scala-lang.org/overviews/core/binary-compatibility-for-library-authors.html

So 4.0.0 if you want to break binary compatibility.

I vote to keep binary compatibility. I think that a lot of bug fixes can be done without breaking binary compatibility.

Maybe let's write 3 lists of pull requests that either:

absolutely need breaking bincompat to work
don't break bincompat at all
want to break bincompat to make code clean(er), but can work without breaking bincompat

Naturally we can do both. We can have master be the branch for the breaking changes and then cherry-pick from there to a 3.3.x branch

I think David updated the PR not to break bincompat.

…

On Mon, Apr 5, 2021, 5:11 AM Heikki Vesalainen ***@***.***> wrote: Naturally we can do both. We can have master be the branch for the breaking changes and then cherry-pick from there to a 3.3.x branch — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2198 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAYAUFEY5EMAVM7GNRLGALTHF5EHANCNFSM42DEN5GQ> .

The Scala 3 PR breaks compatibility, right? If yes then it should be targeted to 4.0.0 but other things can get into 3.4.0. Should we branch 3.4.x off main and retarget applicable PRs to 3.4.x? Is it even possible to retarget an open PR?

Besides adding Scala 3 support that PR drops 2.12 support. I assume that dropping 2.12 also can't be done in 3.x.x? Or can it?

Also, a 3.3.4 is not relevant at all?

BTW should I convert this issue to a discussion?

@SethTisue

@SethTisue @hvesalai what's involved in a release? Ideally any v* tag would automatically publish a release, from my experience. Maybe I should migrate to github actions before we deal with that though

https://github.com/slick/slick/milestones what are 'Future ideas,' 'Future fix release,' and 'Future feature release'? Which future?

How do we get from there to knowing what should be in what branch and in what tag and release?

@octonato

re: publishing:

Let's figure out publishing when the time comes. I am committed to helping as needed to make that happen. Last time, @octonato did it. I'll either figure it out or ask him to help me, and then once I know what the existing setup is, we can discuss perhaps changing it. I'm relieved to see that Bintray isn't involved, so that means we aren't forced to redo everything — but we could still choose to make changes.

re: issue vs. discussion: doesn't matter to me either way.

no idea about the milestones. we needn't feel bound by how it was done in the past.

re: 3.3.4 vs 3.4.0 vs 4.0.0, I'm fine w/ whatever y'all decide. We don't need to bend over backwards to please users who aren't actively contributing to maintenance. And you don't need to worry about Lightbend there, either -- you can be bold (whatever that means to you) if the other maintainers agree. Our period of commercial support for Slick doesn't expire until later this year, so it's possible that if a customer reports a serious bug, we'd be forced to step in and do a release (3.3.4, presumably) from a branch. But I think that's unlikely to happen, so we don't need to plan for it or worry about it.

I haven't looked at the Scala 3 PR to see what the bincompat situation and/or the 2.12 situation is there.

@SethTisue

@SethTisue, there is a wiki page with the release steps: https://github.com/slick/slick/wiki/Release-steps. I have simply follow it each time.

Artifacts are published to stage repo and then you need to connect to sonatype and promote them.

The release process can be simplified with sbt-ci-release though. If I recall correct, it's using its own solution with a few hacks here and there for signing.

According to https://docs.scala-lang.org/overviews/core/binary-compatibility-for-library-authors.html, a binary incompatible change must go into 4.0.0, and a source incompatible change must go into 3.4.0.

Does that imply that a change that is binary and source compatible should go into 3.3.4? What are other reasons to bump the minor version number? Should we also bump it for "new features"? How is "new feature" defined exactly?

Also, where does forwards compatibility come in? Maybe the time to bump the minor version is when we break forward compatibility?

If that is how it should work then I propose:

main should be for unrestricted changes
There should be a branch 3.4.x with binaryCompatSlickVersion set to "3.3.0" or "3.3.3"
3.3.x should have binaryCompatSlickVersion set to "3.3.0" or "3.3.3", and mimaCheckDirection set to "both"
Most changes should by default have a target branch of 3.3.x. If it fails MiMa then it should should be changed to target 3.4.x. If it still fails MiMa then it should be changed to target main. It seems like I can change the target branch of an existing PR.
Whenever a change is made on 3.3.x, 3.3.x should be merged into 3.4.x. Whenever a change is made on 3.4.x, 3.4.x should be merged into main. Initial merge commits can be created that will prevent such merges from overwriting the MiMa settings.

Thoughts?

We don't need to put any changes to earlier versions, but we can.

The question is, are there any users of older versions who would require some of the changes that we are merging AND can't upgrade to the newest version when it will be released. If so, and we want to cater to them, then we need to cherry-pick the changes also to the older version. If not, then we can just put everything to master and cut a new release from there.

Our project is OK with the latter.

@octonato

@octonato @SethTisue @hvesalai any of you know that know how to do a release want to go over it on a call?

let's cross that bridge once all PRs are merged and everything is actually good to go

Up to you, but I like it better when I have more time to digest information

PRs are merged

@SethTisue any in particular that are important to you to make 3.4.0?

Also, if the author doesn't, will you be able to rebase #2145 ?

I like it better when I have more time to digest information

Okay, well here's what I can see from build.sbt: it looks like everything is all set up to publish to Sonatype, and publishing is done from the developer's individual machine. That developer needs Sonatype credentials that work for com.typesafe.slick, and apparently Renato has those and will be able to pass them on to me.

Going forward, it would be better to be on sbt-ci-release, IMO. (Note that sbt-ci-release includes sbt-dynver.) Perhaps you or another volunteer would like to PR that in the meantime. We could merge such a PR even before we have working publishing credentials; those can be added to the GitHub Actions config later.

any in particular that are important to you to make 3.4.0?

Nope, everything I cared about was merged already. It would have been nice if Scala 3 support had landed in time, but I feel pretty strongly that there's more value in releasing anyway than there is in waiting any longer.

if the author doesn't, will you be able to rebase #2145 ?

Sure

Hmm, so now I have an interesting idea which is probably overengineering but it sounds kind of nice I think:

So, we're talking about how sbt should know what version is being targeted, in a way that makes opening and testing a PR seamless. And GitHub already has a way to express what version a PR is targeting: milestones.

So here's the idea:

It doesn't matter so much what the default value of version is. We could use sbt-dynver, set it manually, or anything else
We set the github action to override the version based on the milestone of the PR. I believe we can do that using something like ${{ github.event.pull_request.pull_request.milestone.title }}. If it passes a regex would use it to override version, presumably concatenating to it "-SNAPSHOT".
I think Release Drafter could be configured to use the milestone version.

Although, I do like Release Drafter's idea of labelling PRs with their level of breakage; this way if there are several open PRs, it can easily be seen which ones can be combined into a non-breaking release and which ones could be merged afterward for a subsequent breaking release.

I like it better when I have more time to digest information

Okay, well here's what I can see from build.sbt: it looks like everything is all set up to publish to Sonatype, and publishing is done from the developer's individual machine. That developer needs Sonatype credentials that work for com.typesafe.slick, and apparently Renato has those and will be able to pass them on to me.

Going forward, it would be better to be on sbt-ci-release, IMO. (Note that sbt-ci-release includes sbt-dynver.) Perhaps you or another volunteer would like to PR that in the meantime. We could merge such a PR even before we have working publishing credentials; those can be added to the GitHub Actions config later.

Right, so basically the credentials would go into github secrets. You can do that at any time.

I've used sbt-ci-release on my own OSS repos, since the bintray shutdown, but only via sbt-github-actions. That said, I based Slick's github actions code off that, so hopefully I'll be able to figure out how to configure it standalone.

publishing is done from the developer's individual machine

It's interesting. I assume you're saying that based on

slick/admin/build.sh

Lines 3 to 15 in fcf0e91

    
           # Setup: 
        
           # - Copy keys to admin/secring.asc, admin/pubring.asc 
        
           #   - Use a new key pair per repository 
        
           # - ssh-keygen -t rsa -b 4096 -C "<github-user-email>" #save as deploykey 
        
           #   - Setup github deploy keys using generated keys, keep a copy of generated keys 
        
           # - cp deploykey deploykey.pub admin/ 
        
           # - openssl rsa -in admin/deploykey -outform pem > admin/deploykey.pem 
        
           # - chmod 400 admin/deploykey.pem 
        
           # - cp ~/.sbt/sonatype.sbt ./ 
        
           # - tar cvf secrets.tar admin/secring.asc sonatype.sbt admin/deploykey.pem 
        
           # - travis encrypt-file secrets.tar --add 
        
           # - rm sonatype.sbt admin/secring.asc admin/deploykey admin/deploykey.pub admin/deploykey.pem secrets.tar 
        
           # - Set passphrase in admin/publish-settings.sbt

However, at the same time, it seems to have been set up to publish based on the tag set in CI:

slick/admin/build.sh

Lines 18 to 19 in 070b33a

    
           if [[ "$TRAVIS_TAG" =~ ^v[0-9]+\.[0-9]+(\.[0-9]+)?(-[A-Za-z0-9-]+)? ]]; then 
        
             echo "Going to release from tag $TRAVIS_TAG!"

Anyway, I would be happy to delete all that and related code, and just do a normal sbt-ci-release setup like I do in my other projects, if that's what you think makes the most sense.

Actually, interesting observation related to that and #2198 (comment): CI already works by overriding the sbt version setting, at least on release.

Oh, weird, I didn't notice the TRAVIS_TAG thing. I don't know what to make of that.

But I guess it doesn't matter, because "a normal sbt-ci-release setup" is exactly what I would suggest, and I'm sure Renato won't object. Almost every repo I work in uses sbt-ci-release, these days.

@nafg

@nafg

@isomarcte to clarify, Slick has not used sbt-dynver. I'm just trying to remove as many manual steps as possible that are required to maintain and release Slick

Ah I see. Well I completely understand that sentiment, that was a major reason I wrote sbt-version-scheme-enforcer. ;)

But (1) it shouldn't be more than one of the above, and (2) everything else that needs to happen should happen automatically (e.g. by inferring versionSchemeEnforcerChangeType from version, or version from versionPolicyIntention or commit messages or PR label or milestone).

Yeah, that makes perfect sense to me and I completely agree. FWIW, I've personally found that just using version sbt key is the easiest way to do this from all of the proposed solutions. If you aren't using sbt-dynver, then if someone making a PR wants to state that breaking changes are intentional, then it is usually a single character change.

Anyway, let me know if I can provide any more help.

Open PRs and their status:

#2275 pending review

Merged

#2238 build failures
#2193 pending changes, but should be included in some form IIUC
#2190 pending response to comments
#2187 not done, should target 4.0.0
#2145 LGTM but needs rebase (I would prefer squash too). Fails for MiMa reasons. I want to see tests pass after rebase/squash are force-pushed -- after #2275 (or an alternative) is merged.

Actually I didn't need to rebase it, closing and reopening synced it to main post-#2275. That's merged too.

I hope to focus on working to Scala 3 compatibility after 3.4.0, but I don't think it should come before because it would be best to have refactoring freedom. For instance the virtual classes pattern isn't allowed so lots of renames will be needed.

Another question is what tasks need to be done with a release besides the act of publishing to maven central. Some that come to mind are:

Creating a github release
Writing release notes, documenting changes, migration instructions (scalafix rules for bonus points), etc.
Updating the docs site
Announcing it

What else is there?

@isomarcte

@isomarcte can we chat somehow?

@nafg

@nafg Sure. Like an audio chat?

@isomarcte

@isomarcte yeah. You can DM me on discord as nafg#1263 or gitter as nafg

@nafg

@nafg I messaged you on discord.

Navigation Menu

Repository navigation

Plan next release #2198

31 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	# Setup:
	# - Copy keys to admin/secring.asc, admin/pubring.asc
	# - Use a new key pair per repository
	# - ssh-keygen -t rsa -b 4096 -C "<github-user-email>" #save as deploykey
	# - Setup github deploy keys using generated keys, keep a copy of generated keys
	# - cp deploykey deploykey.pub admin/
	# - openssl rsa -in admin/deploykey -outform pem > admin/deploykey.pem
	# - chmod 400 admin/deploykey.pem
	# - cp ~/.sbt/sonatype.sbt ./
	# - tar cvf secrets.tar admin/secring.asc sonatype.sbt admin/deploykey.pem
	# - travis encrypt-file secrets.tar --add
	# - rm sonatype.sbt admin/secring.asc admin/deploykey admin/deploykey.pub admin/deploykey.pem secrets.tar
	# - Set passphrase in admin/publish-settings.sbt

	if [[ "$TRAVIS_TAG" =~ ^v[0-9]+\.[0-9]+(\.[0-9]+)?(-[A-Za-z0-9-]+)? ]]; then
	echo "Going to release from tag $TRAVIS_TAG!"

Plan next release #2198

Description

Activity

nafg commented on Mar 31, 2021

hvesalai commented on Mar 31, 2021

tarsa commented on Apr 5, 2021

hvesalai commented on Apr 5, 2021

nafg commented on Apr 5, 2021

nafg commented on Apr 15, 2021

nafg commented on Apr 15, 2021

nafg commented on Apr 15, 2021

nafg commented on Apr 15, 2021

nafg commented on Apr 15, 2021

SethTisue commented on Apr 15, 2021

octonato commented on Apr 16, 2021

nafg commented on Apr 16, 2021

nafg commented on Apr 18, 2021

hvesalai commented on Apr 18, 2021

31 remaining items

nafg commented on Jul 13, 2021

SethTisue commented on Jul 13, 2021

nafg commented on Jul 13, 2021

nafg commented on Jul 13, 2021

nafg commented on Jul 13, 2021

SethTisue commented on Jul 13, 2021

isomarcte commented on Jul 13, 2021

nafg commented on Jul 13, 2021

nafg commented on Jul 14, 2021

nafg commented on Oct 10, 2021

isomarcte commented on Oct 11, 2021

nafg commented on Oct 11, 2021

isomarcte commented on Oct 11, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions