Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Magnus
    @evnu
    we can then bump to a PropEr release version later on (hopefully Kostis doesn't take all year to release a new version :-/)
    But I am not sure if mix excludes pre-versions by default..
    iex(1)> Version.match?("1.1.1-rc", "~> 1.1")
true
iex(2)> Version.match?("1.1.1-rc", "~> 1.1", allow_pre: false)
false
    Magnus
    @evnu
    https://github.com/hexpm/hex/blob/main/lib/hex/version.ex#L47 I think hex does not update to pre versions automatically, unless explicitly allowed
    @alfert what do you think, lets go with RC?
    Klaus Alfert
    @alfert
    @evnu Good idea with the rc version. I will do that on the weekend.
    Klaus Alfert
    @alfert
    It becomes worse. Hex does not like dependencies with git version identifiers: 
    ** (Mix) Stopping package build due to errors.
Dependencies excluded from the package (only Hex packages can be dependencies): proper
    I asked kostis for his release plans in proper-testing/proper#257 Depending from his answer we either wait a little more or need to do some git magic for changing the history of propcheck (.e. rolling back the API in #179 ).
    Magnus
    @evnu
    Hm, that's frustrating. Well, lets see what Kostis says. I would hope that he is able to "simply" release soonish, that would be the best case. If that doesn't work or cannot happen in a timely matter, we could branch from 1.3 and cherry-pick only the bug fix for the configuration issue.
    Klaus Alfert
    @alfert
    Kostis is actively discussion tickets but not my comment. I take this as an indicator, that he either does not want to release soonish or does not want to interact with downstream dependencies. I prepare now 1.3.1-rc1 on its own release-branch.
    Magnus
    @evnu
    Yes, makes sense.
    Magnus
    @evnu
    https://github.com/proper-testing/proper/issues/257#issuecomment-841844870 seems like Kostis wants to release!
    Magnus
    @evnu
    alfert/propcheck#200 I created a PR to run CI against the current PropEr HEAD
    Magnus
    @evnu
    Judging from CI, we should be all-right w.r.t. the next PropEr release
    Klaus Alfert
    @alfert
    Yeah, I saw it also and look forward to the new Proper release! There are some new feature that we should support - at least for OTP24
    Klaus Alfert
    @alfert
    In proper-testing/proper#272 there are new types and thus generators for OTP24. I am thinking of introducing these types but only if you are compiling under OTP24. Does that makes sense? Or do we need a new minimal supported OTP variant?
    Magnus
    @evnu
    PropCheck does not create generators from types, so I think it should not hurt to have those generators for OTP < 24 as well, right?
    Klaus Alfert
    @alfert
    So we would simply provide generators nonempty_bitstring()and nonempty_binary() pointing to the new implementations? To be honest, I did not really understand if the generators are new or if it is only the generator for type specification, so we don't care.
    Magnus
    @evnu
    As PropEr supports OTP 20-24, I think simply adding those generators should be fine for us.
    Ah, but I think you are right.. Maybe those generators come into use when deriving generators from types.
    Maybe we should just do nothing then? PropCheck does not implement other type-specific generators such as nonempty_list() or maybe_improper_list() and so on either.
    Klaus Alfert
    @alfert
    That's a good point. And it would explain, why I was so confused yesterday evening while checking the diffs from proper-testing/proper#272 So let's not do anything for that.
    Magnus
    @evnu
    alfert/propcheck#200 Would you like that to be merged, or should we close and simply update to the new PropEr release when it is released?
    Klaus Alfert
    @alfert
    I have now also found that nonempty_binary() is a new type introduced in the type specs for OTP24

    alfert/propcheck#200 Would you like that to be merged, or should we close and simply update to the new PropEr release when it is released?

    I guess we don't need to merge, we simply wait for the release, upgrade then the dependencies and release PropCheck 1.4

    Magnus
    @evnu
    Can't wait for it, the broken stacktraces with OTP 23 bug me a lot :D
    Klaus Alfert
    @alfert
    Next week all should be good again :-)
    Klaus Alfert
    @alfert
    Proper 1.4 is there
    Magnus
    @evnu
    that was fast! Thanks! :)
    Klaus Alfert
    @alfert
    But my release was mixconfigured. Grrrr. Wait for 30 minutes
    Magnus
    @evnu
    Ok! Did you yank the version?
    Klaus Alfert
    @alfert
    Somewhere was a -dev to much in the configs. I will revert the published hex package and do it again.
    Magnus
    @evnu
    :+1:
    Klaus Alfert
    @alfert
    My next project will be a release manager in and for Elixir :-)
    Magnus
    @evnu
    https://github.com/alfert/propcheck/blob/master/mix.exs#L91 maybe remove the commented dependency as well :)

    My next project will be a release manager in and for Elixir :-)

    Hehe :) In the end, everybody writes shell scripts to automate releases :D

    Klaus Alfert
    @alfert
    for a good reason, but the sed command failed. Bug report is under the way
    PropCheck 1.4.0 is there.
    Magnus
    @evnu
    Cool. I will give it a spin on our CI as well.
    Magnus
    @evnu
    worked like a charm.
    Klaus Alfert
    @alfert
    :+1:
    Magnus
    @evnu
    alfert/propcheck#7 Do you still plan to extend PropCheck to other implementations?
    Klaus Alfert
    @alfert
    No, not really. This was a fiction/reminder to myself when I started. But the other implementations diverged to strong, in particular with the advent of StreamData it did not really make sense since it is way too different.
    Magnus
    @evnu
    Ok, lets close the issue then?
    Klaus Alfert
    @alfert
    yep, cleaning up is good.
    Magnus
    @evnu
    @alfert alfert/propcheck#206