--- Log opened Mon Nov 16 00:00:18 2020
00:23 -!- zoe_ [uid464843@gateway/web/irccloud.com/x-mgsluagaejixcikw] has joined #lnp-bp
01:14 -!- dieeasy [uid472335@gateway/web/irccloud.com/x-ulmthsqwggfkkzil] has joined #lnp-bp
02:32 < dr-orlovsky> Sure, answering in GitHub
02:33 < dieeasy> @dr-orlovsky, while preparing PR #141 I thought it might be useful to add a workflow that checks the publish operation, to prevent adding Cargo.toml changes that would break it (e.g. the lightning-invoice dep)
02:33 < dieeasy> I had a quick test and if you find it interesting I'd submit a PR for that (and then probably add it to every project that's published)
02:37 -!- step_ [uid472302@gateway/web/irccloud.com/x-qtiikzxxarmrdogm] has joined #lnp-bp
02:47 < dr-orlovsky> dieeasy: not sure that will work since between publications we need those publish-preventing changes (like relying on github master of LNP/BP Core Lib in RGB Node etc)
02:49 < dieeasy> I just had a quick thought about that and I think master should never have breaking changes merged into, so we can enable this workflow for master only and have breaking changes go to other branches
02:57 < dr-orlovsky> not at this stage of maturity yet; it will just create a lot of headache for me since I am anyway write ~90% of code
02:59 < dr-orlovsky> I tried something like that with rust-amplify and started spending +30% of my time just on creating, "reviewing" and merging my own PRs whenever I need something to be changed b/c in some other project I quickly need some fix or improvements in the underlying library
03:14 < dieeasy> I guessed using branches in Cargo.toml dependencies would have been enough to cater for that need, using PRs to merge topic branches isn't mandatory so you can just keep merging locally into master and pushing once you're done, the publish workflow would just give you additional confidence it'll publish when you choose to do so
04:25 < dr-orlovsky> yeah, but I am not doing development locally and need to sync repos accross devices, VMs and servers, and usually do that through github. Of course we can introduce "develop" branch, but PRs from others will be proposed to master, so I will have to also make my PRs and merge them as well, which gives us exactly the situation I am trying to avoid as explained above
04:26 < dr-orlovsky> I think about NY it will be a time where we can make this proposal live, but before that it will create a lot of unneeded time consumption for me
10:13 < dieeasy> I actually think using a "develop" branch would be the perfect fit: setting it as default branch would automatically target it for PRs, you can still manually merge into it and push whenever you need to sync other devices, while master remains the reference branch for the latest ok/released version (passes CI, no blocking issues, etc.)
10:15 < dieeasy> aside from an hypotetic develop branch (can be discusses separately), are you ok with me opening a draft publish PR so it's done and we can just choose when the time's right to merge it?
12:01 -!- step_ [uid472302@gateway/web/irccloud.com/x-qtiikzxxarmrdogm] has quit [Quit: Connection closed for inactivity]
12:22 -!- zoe_ [uid464843@gateway/web/irccloud.com/x-mgsluagaejixcikw] has quit [Quit: Connection closed for inactivity]
13:30 < dr-orlovsky> dieeasy: I like both ideas, feel free to do a PR
15:14 -!- dieeasy [uid472335@gateway/web/irccloud.com/x-ulmthsqwggfkkzil] has quit [Quit: Connection closed for inactivity]
--- Log closed Tue Nov 17 00:00:19 2020