Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Nov 30 08:58

    mergify[bot] on master

    Update cats-effect to 3.3.0 Merge pull request #648 from sc… (compare)

  • Nov 30 08:58
    mergify[bot] closed #648
  • Nov 30 08:55

    mergify[bot] on master

    Update scalafmt-core to 3.2.0 Merge pull request #647 from sc… (compare)

  • Nov 30 08:55
    mergify[bot] closed #647
  • Nov 30 08:53
    scala-steward opened #648
  • Nov 30 08:50
    scala-steward opened #647
  • Nov 28 07:32
    mergify[bot] closed #646
  • Nov 28 07:32

    mergify[bot] on master

    Update cats-kernel-laws, cats-l… Merge pull request #646 from sc… (compare)

  • Nov 28 07:26
    scala-steward opened #646
  • Nov 22 20:30

    mergify[bot] on master

    Update zio-interop-cats to 3.2.… Merge pull request #645 from sc… (compare)

  • Nov 22 20:30
    mergify[bot] closed #645
  • Nov 22 20:23
    scala-steward opened #645
  • Nov 22 13:05

    mergify[bot] on master

    Update scalafmt-core to 3.1.2 Merge pull request #644 from sc… (compare)

  • Nov 22 13:05
    mergify[bot] closed #644
  • Nov 22 13:00
    scala-steward opened #644
  • Nov 15 13:48

    mergify[bot] on master

    Update amqp-client to 5.14.0 Merge pull request #643 from sc… (compare)

  • Nov 15 13:48
    mergify[bot] closed #643
  • Nov 15 13:42
    scala-steward opened #643
  • Nov 13 01:10

    mergify[bot] on master

    Update scalafmt-core to 3.1.1 Merge pull request #642 from sc… (compare)

  • Nov 13 01:10
    mergify[bot] closed #642
catostrophe
@catostrophe
I hope this works with PRs not only issues.
Gabriel Volpe
@gvolpe
If you're interested in becoming a maintainer, let me know. I'd be happy to grant you permissions
Yes, it works with PRs too
It's not a responsibility, you do whatever you can when you can, this is OSS :)
So for example, making a release would just be creating a new release (which creates a tag) and writing down the release notes
catostrophe
@catostrophe
Regarding becoming a maintainer, thanks, I will think.
And thanks for the quick reaction
Gabriel Volpe
@gvolpe
:+1:
Gabriel Volpe
@gvolpe

I cut a long overdue new release (sorry for the delay): https://github.com/profunktor/fs2-rabbit/releases/tag/v2.2.0

Thanks to everyone involved: @catostrophe @Daenyth @DougC @bpholt @kubum :tada:

Gavin Bisesi
@Daenyth
Awesome :)
Gabriel Volpe
@gvolpe
@Daenyth any objections to cut a new major release v2.3.0 to include @aywengo 's changes?
Gavin Bisesi
@Daenyth
Would be 3.0.0 I believe
but yeah, let's go for it
Gabriel Volpe
@gvolpe
Is that necessary, though? We only maintain a single branch anyway :grimacing:
Gavin Bisesi
@Daenyth
It's not a binary compatible update
if we want to say that we break bincompat in minor semver releases, then it can be 2.3.0. But the scala community is much more that minor keeps compat, major breaks it
I should get mima set up..
Gabriel Volpe
@gvolpe
I don't really mind, you're a real user so if 3.0.0 is preferable I'll go for it
Gavin Bisesi
@Daenyth
It is - it could actually cause us link errors since we have intermediate jars using fs2-rabbit
Hence my suggestion to hide the case class behind a builder-shaped trait
Gabriel Volpe
@gvolpe
What I don't understand is updating to 2.3.0 or 3.0.0 would cause the same issue if any
Gavin Bisesi
@Daenyth
Version number is meaningless - it's just a communication tool
Scala ecosystem generally tells us that minor version bumps are compatible, so someone could update one of the applications without realizing it would break things (and I don't necessarily trust everyone's code coverage ;) )
Gabriel Volpe
@gvolpe
Right, I'll let you handle that then, I set up a release drafter action so you don't even need to write up the release notes, just tag a new version and you'll have the release notes ready (might need some polishing)
Gavin Bisesi
@Daenyth
I'll be a bit busy today - it's totally the same release process just with a different number
I need to take a look at the drafter, been wanting to set that up at work too :)
Gabriel Volpe
@gvolpe
It's not perfect but it's something. You should look at the scala steward repo, it does it better, I'm going to still some stuff from it :D
Gavin Bisesi
@Daenyth
nice
Gabriel Volpe
@gvolpe
Gavin Bisesi
@Daenyth

@gvolpe It's a good idea! One thing that would help remove your need to spend time is to get the release process a bit more automated (or documented).

Right now I'm not sure how to go about it. Also we'll want to make a new major version release with the PR I just merged ;)

Gabriel Volpe
@gvolpe

@Daenyth cutting a new release couldn't be simpler:

Monitor the automatic release job once done. It works 99.9% of the time but when it doesn't we need to login in Sonatype and drop the release manually. Then retry the GH action for the release.

Gavin Bisesi
@Daenyth
oh nice :)
Gavin Bisesi
@Daenyth
looking at past history, it looks like we're going with a "break bincompat in minor releases"
so I'll make 2.3.0 for the next
I think we can set up release drafter to categorize those with tags on prs or something
hmm but previous releases we've done have preserved bincompat in minor releases, rather than updating compatible changes as patch versions
@gvolpe I think I'd like to set a policy going forward of doing bincompat breaks with major versions, and changes that preserve compat being minor or patch. Thoughts?
Gabriel Volpe
@gvolpe
Yeah that should be ideal, go for it :+1:
Gavin Bisesi
@Daenyth
kk
actually before I do that
nvm
I was thinking of using the @data case class replacement library for helping with binary compat but I don't really want to add the dep
will tackle that part later
Gavin Bisesi
@Daenyth

Where does the release thing happen?

I did the release on github and I don't see a new build in here: https://github.com/profunktor/fs2-rabbit/actions

Gabriel Volpe
@gvolpe
Let me see..
Hmm that's odd. The new tag should have triggered a release job like this one: https://github.com/profunktor/fs2-rabbit/actions/runs/257305157
Gabriel Volpe
@gvolpe
I think it might be related to permissions (re: Github Actions being the author of the tag)
Gavin Bisesi
@Daenyth
hm
Gabriel Volpe
@gvolpe
An action in a workflow run can’t trigger a new workflow run. For example, if an action pushes code using the repository’s GITHUB_TOKEN, a new workflow will not run even when the repository contains a workflow configured to run when push events occur.