[12:02:59] DaveMethvin, m_gol, markelog https://docs.google.com/document/d/1uhcW9_TlSwD8JnO1_HNnSYJAriTK9WYZ8uQNDvtAAhA/edit# [12:03:05] hey-hey [12:03:05] here [12:03:41] how goes it [12:03:47] happy mlk day! [12:03:59] what day? [12:04:06] I'm not working today, but we'll do a quick meeting. [12:04:09] it's a holiday here in the us [12:04:10] oh, happy holiday! [12:04:13] martin luther king day [12:04:16] we have a lot of holidays [12:04:21] we have more! [12:04:23] ) [12:04:37] russia is just one big holiday! [12:04:48] side note, I'm on a PC! [12:04:52] whoa [12:04:57] gaming computer [12:05:03] finished it yesterday [12:05:05] bootcamp! [12:05:16] ha, I still have the mac for dev [12:05:21] what the name of game? [12:05:30] all of them [12:05:32] all the games [12:05:33] )) [12:05:37] lol [12:05:41] solitaire [12:05:47] minesweeper [12:05:47] ha [12:05:54] chess [12:05:56] those are the only ones I do [12:06:26] didn't play for a while now, makes me sad :/ [12:06:27] so [12:06:39] DaveMethvin:how's migrate 3.0? [12:06:44] yeah [12:06:51] i have thought about it but nothing done yet [12:06:56] i don't think it's too hard tho [12:07:12] i was wondering if we wanted to have a 2.0 that only supported the latest 1.x/2.x [12:07:18] right now we try to work with every jquery [12:07:20] present [12:07:28] and i agree with gibson042 that isn't fun or good [12:07:40] yeah, we talked about it in nyc [12:07:48] Anything not on the 3.0 milestone on github? [12:07:50] didn't come up with the solution though? [12:08:07] there is tickets for 2.x/1.x right? [12:08:14] oh there's stuff on the milestone [12:08:18] I like the idea of a separate version for 3.0 [12:08:19] just nothing written yet [12:08:35] yeah, we just need to talk out how we will document/explain the process to users [12:08:46] right now it's "drop Migrate into your page" [12:08:55] which is cool! [12:09:03] now there is a multi-step process [12:09:13] so i'd like to be sure we have that defined before i write code [12:09:26] well, to be fair, it was multi-step before. drop migrate into your page, fixes issues, remove migrate [12:09:41] fix* [12:09:43] so maybe a migrate 2.0 would support 11.2.x/2.2.x only [12:09:54] 1.11 [12:10:01] yeah, my thoughts too [12:10:03] 1.12? [12:10:18] so the first step would be to drop in migrate 2.0, it would tell you to upgrade your jquery to the latest if you didn't already [12:10:29] the latest 1.12/2.2 [12:10:46] makes sense [12:11:05] then once you got that straightened out you would remove migrate 2.0 and the old jquery, add migrate 3.0 and jquery 3.0 [12:11:19] it would again give you a list of stuff to fix [12:11:37] thing is, we also have to handle the scenario where it's just used as a version shim [12:11:45] which is BY FAR the most common [12:11:51] a lot of people might do that [12:11:51] since Wordpress includes it by default always [12:12:08] maybe we need a migrate for the migrate? [12:12:11] ) [12:12:17] yeah there was some talk of that [12:12:25] god, no [12:12:25] wordpress includes it by default? ugh [12:12:28] oh, i was kidding [12:12:37] I don't think others were [12:12:44] that is unfortunate [12:12:51] the reason we were doing the two step process was to avoid having, for example, attroperties shims in place at the same time someone was trying to do 3.0 stuff [12:12:54] but understandable [12:13:25] since migrate wouldn't give all list of stuff to fix [12:13:37] it just becomes unworkable to try and shim a jquery 1.6 tooltip plugin with jquery 3.0 [12:14:01] only things that could be statically identified and the methods which were called [12:14:09] yea, plugins will need to start specifying supported jquery versions, like with node modules [12:14:36] that would be ideal but i think the ship has sailed [12:14:43] so now everyone is doing that manually [12:14:47] and not knowing if it will work [12:15:04] and that's where migrate comes in handy, but only for a range of versions [12:15:11] i think we'll need to talk at least to wordpress and find out what they are going to do [12:15:21] i can do that [12:15:41] dunno when/if they are planning a move to 1.12 [12:15:50] the "migrate as revert one major" model probably works for them, though [12:16:21] i wonder if wp will ever be able to go to 3.0 anyway [12:16:35] because of IE8? [12:16:36] depends on their browser support, right? [12:16:50] because they have so many themes that would break [12:17:06] and including two shims is impractical most likely [12:17:48] mainly i'd like to have a migrate 2.0 so we don't have to support jquery 1.7---2.2 with the same plugin, and just support 2.2 [12:17:55] tbh I'd like to follow the Ember/QUnit route and drop Migrate completely, instead having deprecations baked in [12:18:11] mechanism would be to introduce all the new APIs in minor releases, together with deprecations [12:18:24] major releases would mostly do one thing - drop deprecated APIs/behaviors [12:18:31] i don't think that would work for our ecosystem though [12:18:50] then you have the comfort that if you fixed all of your deprecations (at your own pace!) you can upgrade without any problems [12:18:51] ember is relatively young, low volume, and most of its projects are churned frequently [12:19:01] legacy is always a tough issue [12:19:03] DaveMethvin:are you saying migrate 2.0 would be for upgrading to 1.12/2.2 and migrate 1 would be to get to 1.11/2.1? [12:19:05] jquery projects are not [12:19:34] DaveMethvin: at the nyc, we talked about automatically updating code [12:19:35] DaveMethvin: why not? this is, in effect, similar to your proposal to have Migrate "downgrade" only to one version below [12:19:38] seems like the current migrate is ok for getting to 1.12/2.2 [12:19:38] you can still do tha [12:19:39] t [12:19:41] but it avoids a separate pakage [12:20:00] which i believe would solve everything [12:20:07] I was thinking we'd have a migrate 3.0 for jQuery 3.0 [12:20:09] timmywil: no, just that migrate 2.0 would tell ppl "i don't care what version you're on right now, install 1.12/2.2 and migrate will try to shim it" [12:20:19] you would just run "migrate src" and be done with it [12:20:42] rather than "throw any version from 1.7.0 to 2.2.x at us and migrate will try to shim it" [12:20:57] that's what we do today [12:21:05] I see, so there's migrate for old versions that has the same paradigm as migrate 3.0 [12:21:12] yes, there will be a 3.0 migrate as well [12:21:34] and yeah we'd just try to make the rules similar so that it would be easier to understand what to do [12:21:34] DaveMethvin:what does the latest migrate do? [12:21:57] it tries to shim whatever jquery it gets with the old behaviors [12:21:58] migrate tries to shim it regardless of version I guess [12:22:01] yeah [12:22:38] interesting. I'm on the fence. We have a migrate that works okay from 1.7 to 2.2, right? Do we really want to change it? [12:22:46] sometimes forward and sometimes backward [12:22:47] blech [12:23:21] how about if it warns if you're not using 1.12/2.2 but tries anyway? [12:23:27] so that would be one of the warnings [12:23:30] I guess it's worth encouraging people to upgrade to latest 1.x/2.x [12:23:36] yeah [12:23:57] but it seems unnecessary to remove all the work we did for previous versions [12:24:07] I like the warning idea [12:24:08] I pretty much only care about Migrate 3.0, which should have the job of building a 2.2 interface on top of 3.x [12:24:10] only if we never have to change it again [12:24:31] well, hopefully, we won't...at least not significantly [12:24:56] migrate 3.0 is almost a separate project [12:25:22] ok then i think what I'll do is just add the version warning to the existing 1.3.0 and encourage users to upgrade to that [12:25:36] cool [12:25:41] so, migrate 3.0 [12:25:52] there are a bunch of open tickets if ppl want to tackle them [12:26:12] https://github.com/jquery/jquery-migrate/issues?q=is%3Aopen+is%3Aissue+milestone%3A3.0.0 [12:26:25] i think we're probably missing some [12:26:51] it's also a bit tricky b/c we change behavior of things like .then and need to decide what to do there [12:26:57] I can help with some [12:27:20] let's just do 3.0 against master and create a 1.x-stable for patches to the old one [12:28:03] i also suspect we're missing some changes here [12:28:04] I like that [12:28:23] can we think of anything right now? could add some. [12:29:10] https://github.com/jquery/jquery/issues?utf8=✓&q=is%3Aissue+is%3Aclosed+milestone%3A3.0.0+label%3A"Behavior+Change" [12:29:26] ha, was just about to link that [12:29:29] ok, my remarks about wanting the Migrate gone in favor of a QUnit/Ember-like policy are about Migrate 4, not 3 [12:29:29] i don't think they ALL need a warning but that may be a good start [12:30:14] isNumeric probably doesn't need a warning. [12:30:57] i already have several of these warnings in place for the 1.3.0 migrate b/c they were deprecated [12:31:43] it seems only two bosses talking right now, i'm scared [12:31:46] isNumeric should have a warning... we restricted the signature [12:31:48] ) [12:32:09] every behaviour change should have one, i think [12:32:16] yes [12:32:30] hey, pop in a new ticket if you think it needs one ... just be sure to think about how we can do it [12:32:56] okay, just seems incredibly rare [12:33:16] like the change to progress events in jQuery.when() could be shimmed but is pretty rare too [12:33:21] if it was significant enough to change the public API, it's significant enough for Migrate [12:33:22] sure [12:33:26] on some of these we might want to wait until it's proven to be needed [12:33:43] note that the jQuery.when progress handling was NOT documented [12:33:50] yeah [12:33:53] true that [12:33:58] gibson042:the change to the api was more clarifying than breaking [12:34:44] yeah mainly i just don't want to write a bunch of tricky shims unless we need them [12:34:50] I'd argue, but it's such an easy fix that the coding is quicker than the debate [12:35:01] fair enough [12:35:03] https://github.com/jquery/jquery/issues/2662 [12:35:06] hey if we have a volunteer then go for it! [12:35:06] this one, right? [12:35:27] btw, thanks to DaveMethvin for doing such a great job with migrate! [12:35:35] second that [12:35:37] yup [12:35:39] def [12:35:50] aw thanks, and esp for all your help [12:36:01] \o/ [12:36:28] feel free to grab any of those tix or create new ones if you think we need them [12:36:47] will take at least one [12:37:02] what should we do about the big things like the behavior changes in .then? We could map that into .done().fail() i guess [12:37:15] but we don't know if they need that crutch [12:37:28] https://github.com/jquery/jquery-migrate/issues/134 [12:37:53] DaveMethvin: I can take the .then work [12:38:01] ok thanks gibson042 [12:38:02] that's a tough one, one I'd want gibson042 to do :) [12:38:17] we all did i think ) [12:38:20] silently ) [12:38:32] * DaveMethvin uncrosses fingers [12:38:36] it's nice to feel needed :) [12:38:58] jQuery.support? [12:39:13] properties were not documented right? [12:39:24] i know there are plugins that use the object, but mainly to drop their own stuff in it [12:39:27] they were documented as changeable [12:39:32] so just having it there is probably enough of a shim [12:39:39] so it just could be an object? [12:39:44] yeah i think [12:39:45] yea, I think so [12:39:50] I think so too [12:39:54] easy enough ) [12:40:05] all the undocumented stuff is case-by-case anyway [12:40:19] what about jQuery.support? Is there an issue or sth? [12:40:29] timmywil just created one [12:40:36] ah, in the context or Migrate only? [12:40:52] in that case I agree, this has always been private [12:40:56] https://github.com/jquery/jquery-migrate/issues/135 [12:41:01] fast [12:41:38] why would it not exist? what scenario are we trying to workaround? [12:41:48] the good thing about supporting only the latest version is that once we stop exposing it then Migrate can treat all uses as warnings [12:41:59] although, it is still exist in 3.0 [12:42:04] exactly [12:42:27] so we could table that issue [12:42:27] It wasn't removed for 3.0, but we closed it still open to the idea. I guess migrate doesn't need that yet. [12:42:49] https://github.com/jquery/jquery/issues/2289#issuecomment-114174071 [12:42:50] btw [12:43:29] we would need some work and one clever idea to make that happen [12:43:54] once we can start depending on ES5/6 features, or at least optionally using them, the warnings can get smarter [12:44:18] we need to create a ticket about those es6 featires [12:44:22] features [12:44:30] idea keep poping up [12:44:50] it's more of an implementation tho, if you can see a place where we can use it today we can do it [12:45:19] i'd prefer to avoid a generic ticket that just says "use es5/6 where possible" [12:45:52] like, we could use Proxy to see when people are writing custom properties into jQuery.support [12:46:11] i think we can use imports [12:46:18] but now we using amd [12:46:26] not sure how we can unite those approches [12:46:46] timmywil: i think the ready event shim is already in 1.3.0 [12:46:49] let me check [12:47:19] From the commit message, it sounds it was just warning. [12:48:24] the ready event is kind of strange since it only fires at the exact point of ready [12:48:40] maybe we should discuss migrate issues in -dev? [12:48:44] yeah good point [12:48:53] is there anything else? [12:49:12] I've deferred issues needing review until next week, devoting this meeting to migrate. [12:49:21] do you want to talk about show/hide? [12:49:31] sure, that wasn't even on my list [12:49:34] shoot [12:49:41] yeah, it is simple [12:49:53] i need to comment one more time ) [12:49:58] ok [12:50:01] at the github [12:50:05] i'm a bit busy [12:50:11] but should have time tomorrow [12:50:11] likewise [12:50:13] i read thru the full discussion yesterday and finally understand what gibson042 was saying [12:50:21] GitHub is a fine place for the discussion [12:50:25] and i'm good with it [12:50:29] I still like it [12:50:50] i guess you also need to understand my point ) [12:50:57] but we can keep the discussion going on github. I'm interested to read markelog's next comment. [12:51:16] i can explain it right now, if you want [12:51:21] but it might take awhile [12:51:29] let's put it on the pr [12:51:31] or the ticket [12:51:35] ok-ok [12:51:38] i have one thing [12:51:42] one thing about .on(event, undefined) [12:51:52] currently discussion is in the commit [12:52:04] we put the behavior back in 1.12/2.2 bc it was a regression of undocumented behavior [12:52:13] it's currently not in 3.0 [12:52:15] shoudl it be? [12:52:28] we know there are people using it [12:52:32] That's ok, I'm moving some major discussions to next week because I expect this week to be a light week. We worked hard to get 1.12/2.2 and 3.0 beta out. We can take it easy this week. [12:52:33] it might be useful [12:52:48] in a pattern when you're attaching handlers as properties of an object [12:52:50] timmywil: yeah to us! [12:53:05] that someone might not set on purpose, treating it as an optional parameter of sorts [12:53:12] yeah the example the person posted seemed like it could be reasonable and changed my mind [12:53:31] that's what bootstrap-markdown used [12:53:33] if we want to put it back in 3.0 we should also document it [12:53:38] definitely [12:53:56] and maybe plan for a 1.12.1/2.2.1 in a couple of weeks [12:53:58] we could even state it's been supported for a long time [12:54:03] yeah [12:54:07] agreed. DaveMethvin: could you open an issue on jquery? [12:54:09] but we need to get 2.2.1 released first so that we're not lying ;) [12:54:09] sure [12:54:24] about the support [12:54:38] timmywil: you didn't remove the milestone at https://github.com/jquery/jquery-migrate/issues/135, causing the issue to be though as fixed for Migrate 3 [12:54:49] I see that as a common problem... [12:54:56] removed [12:55:02] should we have a bot that lies at us or sth? [12:55:17] * s/lies/shouts/ [12:55:35] It's not terrible. While it wasn't "fixed", it's still related to that milestone. [12:55:57] "You closed an issue with a milestone manually. If it's not going to get fixed, please remove a milestone." or sth [12:56:00] I know that makes the changelog misleading, so I'm fine with removing the milestone. [12:56:13] yeah, but it happens all the time [12:56:17] this is another place where some simple changes to GH issues would make our lives simpler [12:56:28] sometimes in the wontfix case [12:56:30] closing with a resolution could remove or require milestones [12:56:44] yea, would be nice to have different resolutions [12:56:47] and it'd be really bad to put sth that we wontfixed in the changelog as fixed... [12:57:03] btw if you haven't already, go over to https://github.com/dear-github/dear-github and follow the link to sign if you want [12:57:14] I done did it [12:57:44] it was nice to see lots of familiar names in there :-) [12:57:44] although I agree with the problems, I think "completely ignored" is too strong [12:57:50] but I still signed it [12:58:26] oh also btw i'm working on a jsdom patch for that problem they have with our new parseHTML [12:58:36] that's great! thanks! [12:58:46] also came up with a way to work around it in the support test if needed for 2.2.1 [12:59:01] but i want to see if i can figure out jsdob [12:59:04] jsdom* [12:59:18] ok gotta go [12:59:22] me too [12:59:27] we'll stop 1 min early [12:59:32] it was a long quick meeting indeed ) [12:59:40] indeed [12:59:47] but productive! [12:59:49] thanks all!