00:14 <ckanbot> [CKAN] HebaruSan opened pull request #2430: Ignore conflicts between versions of same mod (master...fix/self-conflict-upgrade) https://git.io/vplzJ

00:14 <ckanbot> [CKAN] HebaruSan commented on issue #2430: Tests in progress... https://git.io/vplzU

00:22 <ckanbot> [CKAN] HebaruSan commented on issue #2430: Tests in progress... https://git.io/vplzU

01:00 <ckanbot> [CKAN] HebaruSan pushed 1 new commit to master: https://git.io/vpl2l

01:00 <ckanbot> CKAN/master 12a8a1c HebaruSan: Add 1.4.3 to embedded build map

04:43 <ckanbot> [CKAN] politas commented on issue #2428: It sounds like we need a more robust model of a "change" that involves "(remove [a,b,c,..]) and (add [x,y,x,...])" and stop trying to consider "upgrade" as a unique change type. https://git.io/vpl67

05:02 <ckanbot> [CKAN] politas pushed 2 new commits to master: https://git.io/vpliR

05:02 <ckanbot> CKAN/master 9472385 Paul Hebble: Ignore conflicts between versions of same mod

05:02 <ckanbot> CKAN/master 4497114 Myk: Merge #2430 Ignore conflicts between versions of same mod

05:03 <ckanbot> [CKAN] politas closed issue #2428: Self-conflicts treated as actual conflicts at upgrade https://git.io/vpWiT

05:14 <ckanbot> [CKAN] politas commented on issue #2418: What build fail? :grinning: https://git.io/vplid

05:48 <ckanbot> [CKAN] politas commented on issue #2429: I can see the logic behind putting the loop in MarkAllUpdatesToolButton_Click and having the single mark for update code in MainModList. It makes the MarkModForUpdate method more reusable, and puts the logic of "Mark all available updates" where it arguably should be (attached to the button that the user clicks to do that).... https://git.io/vplXt

06:01 <ckanbot> [CKAN] politas pushed 1 new commit to master: https://git.io/vplXS

06:01 <ckanbot> CKAN/master ee19245 Myk: It's 2018 now

06:07 <ckanbot> [CKAN] politas commented on issue #2342: >Running CKAN in administrator mode fixes this for me.... https://git.io/vpl1I

06:19 <ckanbot> [CKAN] DasSkelett commented on issue #2429: I'm not sure if I can follow you exactly.... https://git.io/vpl1a

06:23 <ckanbot> [CKAN] HebaruSan commented on issue #2429: There is a map from identifier => row, see `MarkModForInstall`:... https://git.io/vpl19

09:47 <ckanbot> [CKAN] Sunesha commented on issue #2428: Experienced as reported in first post. Only seen this concerning the mods "Scatterer" and "VesselMover Continued". https://git.io/vplAr

10:10 <ckanbot> [CKAN] politas commented on issue #2398: Ok, a few questions that may help explain why we aren't jumping on this idea:... https://git.io/vplpi

10:26 <ckanbot> [CKAN] politas commented on issue #2429: So before your changes, it was split up . You've basically merged the two elements (Find all mods which have updates) fromMarkAllUpdatesToolButton_Click and (Change the update checkbox) from MarkModForUpdate. If we change MarkModForUpdate to get the relevant row using `DataGridViewRow row = mainModList.full_list_of_mod_rows[identifier];` then we get rid of the inefficiency and keep the concept of a method doing

10:57 <ckanbot> [CKAN] politas commented on issue #2377: I was thinking about this the other night, and I think we would basically need to write it as a completely separate UI, based on the KSP Install list. Call it CKAN Watcher; it could be run with `ckan.exe watcher`, and have a "launch at startup" option.... https://git.io/vp8ei

11:03 <ckanbot> [CKAN] politas commented on issue #2409: Have you retried the install with a newer CKAN client? https://git.io/vp8vJ

14:02 <ckanbot> [CKAN] DasSkelett commented on issue #2429: So like this now?... https://git.io/vp8GU

14:34 <ckanbot> [CKAN] DasSkelett commented on issue #2429: So like this now?... https://git.io/vp8GU

15:29 <ckanbot> [CKAN] HebaruSan commented on issue #2428: Thanks @Sunesha, VesselMoverContinued fits the profile in this issue (conflicts with itself, but via a `provides` property rather than directly), and it seems to be fixed by the change in #2430. https://git.io/vp8RF

15:39 <ckanbot> [CKAN] yalov commented on issue #2420: empty to "any"? ... https://git.io/vp807

16:41 <ckanbot> [CKAN] HebaruSan opened pull request #2431: Test upgrading mod with conflict on its own provides (master...fix/provides-self-conflict-test) https://git.io/vp8a4

17:45 <ckanbot> [CKAN] yalov opened pull request #2432: Replace max KSP "9.9.9" with "any" and 1.4.99 with 1.4.9 (master...master) https://git.io/vp8Kd

17:52 <ckanbot> [CKAN] HebaruSan commented on issue #2432: I still don't understand why we wouldn't want to display accurately the values from the metadata. https://git.io/vp86r

17:55 <ckanbot> [CKAN] DasSkelett commented on issue #2432: Seems like a good approach to me, but should we really consider a.b.9 as the highest possible a.b version number?... https://git.io/vp86x

17:56 <ckanbot> [CKAN] DasSkelett commented on issue #2432: Seems like a good approach to me, but should we really consider a.b.9 as the highest possible a.b version number?... https://git.io/vp86x

18:05 <ckanbot> [CKAN] yalov commented on issue #2432: `patch` only twice reached .5 so .9 should be ok for the patch.... https://git.io/vp8iD

18:10 <ckanbot> [CKAN] yalov commented on issue #2432: `patch` only twice reached .5 so .9 should be ok for the patch.... https://git.io/vp8iD

18:13 <ckanbot> [CKAN] HebaruSan commented on issue #2432: Regardless of whether we can convince ourselves now that .5 or .9 are safe, it raises the question again of why do this in the first place? It's hard coding a series of dubious assumptions about not just how many patches there will be but how Squad chooses to _represent_ those versions in their numbering scheme. If any of those assumptions is violated in the future, then this code will need to be patched again

18:38 <ckanbot> [CKAN] yalov commented on issue #2432: remove patch changing, but still don't wan't have 99.99.99's https://git.io/vp81o

18:38 <ckanbot> [CKAN] yalov commented on issue #2432: remove patch changing, but still don't want to have 99.99.99's https://git.io/vp81o

18:41 <ckanbot> [CKAN] yalov commented on issue #2432: remove patch changing, but still don't want to have 99.99.99's in the column https://git.io/vp81o

18:42 <ckanbot> [CKAN] yalov commented on issue #2432: removed patch changing, but still don't want to have 99.99.99's in the column https://git.io/vp81o

18:44 <ckanbot> [CKAN] yalov commented on issue #2432: removed patch changing, but still don't want to have 99.99.99's or 1.99.99 in the column https://git.io/vp81o

18:45 <ckanbot> [CKAN] yalov commented on issue #2432: removed patch changing, but still don't want to have 99.99.99's or 1.99.99's in the column https://git.io/vp81o

19:10 <ckanbot> [CKAN] yalov commented on issue #2432: > if Squad ever releases a 1.10 or 2.0 version... https://git.io/vp8ys