Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 02:34

    mergify[bot] on master

    Update scalafmt-core to 3.4.0 Merge pull request #682 from sc… (compare)

  • 02:34
    mergify[bot] closed #682
  • 02:33

    mergify[bot] on master

    Update cats-effect to 3.3.5 Merge pull request #683 from sc… (compare)

  • 02:33
    mergify[bot] closed #683
  • 02:29
    scala-steward opened #683
  • 02:28
    scala-steward opened #682
  • Jan 28 17:58

    mergify[bot] on master

    Update mdoc, sbt-mdoc to 2.3.0 Merge pull request #681 from sc… (compare)

  • Jan 28 17:58
    mergify[bot] closed #681
  • Jan 28 17:52
    scala-steward opened #681
  • Jan 24 13:22

    mergify[bot] on master

    Update scalacheck-1-15 to 3.2.1… Merge pull request #680 from sc… (compare)

  • Jan 24 13:22
    mergify[bot] closed #680
  • Jan 24 13:21

    mergify[bot] on master

    Update scalatest to 3.2.11 Merge pull request #679 from sc… (compare)

  • Jan 24 13:21
    mergify[bot] closed #679
  • Jan 24 13:16
    scala-steward opened #680
  • Jan 24 13:16
    scala-steward opened #679
  • Jan 23 07:41

    mergify[bot] on master

    Update scalafmt-core to 3.3.3 Merge pull request #678 from sc… (compare)

  • Jan 23 07:41
    mergify[bot] closed #678
  • Jan 23 07:36
    scala-steward opened #678
  • Jan 21 00:26

    mergify[bot] on master

    Update scalafmt-core to 3.3.2 Reformat with scalafmt 3.3.2 Merge branch 'master' into upda… and 1 more (compare)

  • Jan 21 00:26
    mergify[bot] closed #677
Saskia Gennrich
@pektinasen

I'm new to rabbitmq and fs2, so my questions might not directly related to fs2-rabbit, but rabbitmq in general. I'm consuming a queue I have no control over, is there a way to tell the queue I only want events that were generated after I created the connection.
I'm getting events from 2 days ago. Which is when I first started consuming events from this queue.
Sorry, for these basic questions.

Is this even something a consumer has control over?

Gavin Bisesi
@Daenyth
yes, ish
You can construct a non-durable queue that gets created on startup and deleted once your consumer disconnects
so it won't be "a queue", it would be "a new queue for each process"
Note that under that model if publishers publish when the consumer is down, the message would be discarded or go to whatever dead-letter routing you have
Gabriel Volpe
@gvolpe
@Daenyth if you need a new release, feel free to cut a new one whenever you need it, you should have the rights to do so. All you need to do is to tag a new version starting withv (e.g. v2.3.0) and write down the release notes. sbt-ci-release will do the rest.
Gavin Bisesi
@Daenyth
:+1: cool
catostrophe
@catostrophe
@Daenyth @gvolpe I just opened a PR to update deps to the latest versions (where Steward failed). Can we have a minor release soon?
Gabriel Volpe
@gvolpe
@catostrophe thanks a lot! Could you edit the description of the PR to link the PRs and Issues it closes? e.g. closes #35 and closes #64, etc
catostrophe
@catostrophe
Sure
Gabriel Volpe
@gvolpe
I already approved it but this would be nice to have so we don't have to come back to track what hasn't been closed / merged, much appreciated it
Note that as soon as the PR is merged, a new SNAPSHOT is published so you can already use that until a release is published
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?