Closed benoitc closed 5 years ago
hahaha, we should do that!
Which version do you think would be the best to tag?
More importantly, it would be useful to find out which version you need and the version that Bondy needs so maybe we need to tag a 1.x branch and a 2.x branch.
I am a little bit behind master 😄 (93 commits). I am still using my fork https://github.com/Leapsight/partisan as I have two commits which fix a missing membership state update only affecting local event handlers resulting in an out-of-sync view of the cluster membership.
I will merge your master branch into mine and see if my change is still required and if so I will do a PR.
I think our version of Plumtree already contains that fix -- I think I also submitted that same fix to the upstream as well.
@aramallo Can you move to HEAD of master and let us know if that would be a good release to tag for 1.x?
Yes, I’ll try to check over the weekend and let you know.
@cmeiklejohn I think anything that is compatible with OTP 22 is fine for me. Do you already have introduced the API changes in the master? Would be good to have them already if it can bring the same level of support for each gossip strategy :)
I don't believe I can bring in those changes for the new membership strategy stuff into master yet because I think Igor and @aramallo both are using the old API. Can you both confirm?
@cmeiklejohn I am currently restructuring/cleaning my code to implement a nicer modular architecture, so that even if the new API breaks everything, I'd be able to switch back to my old fork. For GRiSP, OTP 21 is my current vsn and 22 is already supported too, so like @benoitc everything should be fine for me 🙂 Would it still be compatible with Lasp ?
So, Lasp requires the old version of Partisan (1.x branch) before breaking changes. Therefore, that would have to be upgraded before being able to move to the new version of Partisan.
I guess I am using the old API , anything you can give me to spot the diff with the new API? Is that in a separate branch. On another note , I did some tests today and the changes to the membership update I had fix in my fork are still required in the latest Master branch. So I created a new fork (this time in my personal github space) and will send you a PR tomorrow after I run more tests and explain the case in which the issue arises.
Also @cmeiklejohn i could try to adopt the new API so that we can all start from the same place
Yeah, using the new API would be the best idea, I think.
@cmeiklejohn I see that you have opened a PR to bump Partisan in Lasp, but it is not merged yet, would that be a good starting point ? Anyway, feel free to bring the new features 😄 I am also interested in @aramallo 's approach, I could try out the new API, and see if I can help make it work with Lasp. And also :
anything you can give me to spot the diff with the new API?
Is very welcome as well 🙂
I'm not sure I have cycles for bumping Lasp to the new version of Partisan; so, someone else is going to have to do that work at this point, or we will just leave it pinned to the old version. @Laymer, since you're the primary user of Lasp, it would be cool if you could take a stab at it.
@cmeiklejohn I will definitely try, and since I'm already trying to improve the way I use Lasp on GRiSP, I think I'd be doing even better if I can contribute to Lasp on anything else !
bump :)
@benoitc my apologies for the lack of progress on this. I could not find time to address this properly but I will definitely be working on it after the Erlang workshop, and will update if I manage to make any progress :slightly_smiling_face:
Although there is probably additional requirements that I will have to address in my particular case, such as being able to work without plumtree, and I don't know if this is something that could be useful for Lasp in general as well?
My inclination is to just merge my recent work and tag a new major release. Any objections?
@cmeiklejohn which branch do you have in mind? I wanted to prepare my code to it a little as I am about to release as well.
i'm working on it
@cmeiklejohn I am working with master, I have a fork and will be making a PR in 30 mins because the issue I mentioned before is still standing in master.
ok
Ohhh, I just realised there are 96 new commits to the version I was using....time flies. So I need to double check now.
lol
I was wrong, it is early for my brain to work properly, I have two forks and I was checking the old one. I am now checking the latest one and we still need my PR. Running Partisan test suites now, will comment soon
@cmeiklejohn I get an error with TLS, is the following expected?
2019-08-14 09:17:59.900
Generating TLS certificates into /Volumes/Work/aramallo/partisan/_build/test/logs/ct_run.nonode@nohost.2019-08-14_09.09.35/lib.partisan.logs/run.2019-08-14_09.09.35/log_private/
%%% partisan_SUITE ==> with_tls.init_per_group: FAILED
%%% partisan_SUITE ==> {eval_cmd,1}
%%% partisan_SUITE ==> with_tls.default_manager_test: SKIPPED
%%% partisan_SUITE ==> {tc_auto_skip,{failed,{partisan_SUITE,init_per_group,{'EXIT',{eval_cmd,1}}}}}
%%% partisan_SUITE ==> with_tls.end_per_group: SKIPPED
%%% partisan_SUITE ==> {tc_auto_skip,{failed,{partisan_SUITE,init_per_group,{'EXIT',{eval_cmd,1}}}}}
...............
EXPERIMENTAL: Writing retry specification at /Volumes/Work/aramallo/partisan/_build/test/logs/retry.spec
call rebar3 ct with '--retry' to re-run failing cases.
Skipped 1 (0, 1) tests. Passed 33 tests.
Results written to "/Volumes/Work/aramallo/partisan/_build/test/logs/index.html".
===> Failures occurred running tests: 1
weird, I'm not seeing this. Missing libopenssl-dev?
Ummm...I am on the macOS, maybe wrong lib? So if that is the case your CI should pass the test, so I will go ahead with the PR and check my macOS env for the openssl libs
Yes, the PR passes the tests :-) Let me know if you need more details
Closing, since we just tagged v4.0.0.
awesome. thanks!
I am wondering if a release (tag) can't be cut one of these days on the current code or one of these interresting branches? That would help a lot to release a product above partisan :)