Dev meeting 2016 08 09

Agenda

• Follow-up on having a "Snow Leopard" release
  • 3.2 — Exception handling, caching, request cycle (presently in clean up phase)
  • 3.3 — Meow, unit/functional split, more tests written/replaced
  • 3.4 — Ross vs Storage Layer: The Penultimate Showdown
• jQuery 3.x being added to 3.1
  • Has a lot of BC breaks… should it be in a minor release
  • Should we keep our shipped jQuery loadable for FE users
• JavaScript debug logging
  • Should we add a bolt.log() function, so that we can distinguish between dev only console output and error message like logging
• 3.0.12 and 3.1 beta 2 releases. Good to go? Later this week?

Actionable Items

• Release 2.0.12 — @bobdenotter
• Release 3.1.-beta2 — @bobdenotter
• JavaScript debug log — @rarila

Outcomes

• Proposed release schedule GTG
• 3.0.12 and 3.1 beta 2 releases GTG
• jQuery not a problem, backend only, can be reverted easily in beta
• JavaScript debug log

Log

<gawainlynch> ping Bopp carsonfull gawainlynch phillipp rarila rixbeck rossriley SahAssar slick0 
<SahAssar> pong
<phillipp> still here
<Bopp> pong
<rossriley> checking in
<gawainlynch> Awesome
<gawainlynch> OK, quick one first … 3.0.12 and 3.1 beta 2 releases. Good to go? Later this week?
<SahAssar> We have some nice speedups and fixes in release/3.0, so :+1: for that.
<gawainlynch> Both have my vote, -beta2 just needs a merge from release/3.0 
<Bopp> I'm working on documenting the release proces! 
<Bopp> gawainlynch: if you do the merge, i'll handle the rest of the releases
<gawainlynch> I have my process documented and scripted … but nqr for distribution yet
<Bopp> cool, i'm getting there too
<gawainlynch> Bopp: Yep, post updating src/Version.php
<gawainlynch> Next …
<gawainlynch> Follow-up on having a "Snow Leopard" release
<gawainlynch> 3.2 — Exception handling, caching, request cycle (presently in clean up phase)
<gawainlynch> 3.3 — Meow, unit/functional split, more tests written/replaced
<gawainlynch> 3.4 — Ross vs Storage Layer: The Penultimate Showdown
<gawainlynch> Thoughts?
<rarilaDroid> Peng
<phillipp> looks good for me
<gawainlynch> Evening, rarilaDroid 
<Bopp> I'm fine with that.. Sounds like a good approach to me, to keep the quality high. 
<phillipp> that
<SahAssar> The "Ross vs Storage Layer", is that in preparation for removing legacy storage in 4.0?
<Bopp> what's "Meow", though? 
<phillipp> Bopp: adding cat emojis
<gawainlynch> Yeah, I get your point last week, I just am not convinced 3.2 is the best target, 3.3 makes the most sense as it will have the exception stuff for our debug run
<carsonfull> o/
<gawainlynch> Bopp: Snow Leopard … meow
<Bopp> ah, ok :-)
<gawainlynch> Afternoon, carsonfull 
<gawainlynch> carsonfull: You're good with 3.0.12 and 3.1-beta2 ?
<carsonfull> Yep!
<Bopp> Ok, we'll get on that! 
<gawainlynch> OK … jQuery 3.x being added to 3.1
<gawainlynch> Has a lot of BC breaks… should it be in a minor release
<gawainlynch> Should we keep our shipped jQuery loadable for FE users
<Bopp> Ok, about that.. 
<SahAssar> We should not mix backend and frontend JS/CSS libs IMO.
<Bopp> First of all, it'll be really easy to revert to JQuery 2.2.4..
<gawainlynch> SahAssar: Just that 3.4 would give rossriley plenty of time to get his stuff in order
<rarila> SahAssar: AFAIk we don't mix
<gawainlynch> (re storage thing)
<Bopp> but, I haven't noticed any BC breaks in the backend.. 
<gawainlynch> rarila: If you enable jQuery loading in config
<SahAssar> rarila: Well, isn't it the same jquery version loadable by frontend and that is loaded in backend?
<rarila> SahAssar: AFAIk the backend jquery is included in lib.js
<gawainlynch> OK … my concern lays in that we have a visible config option to load it, therefore production sites could be loading jQuery that way for their themes
<rarila> yep
<SahAssar> rarila: So it is, you're right
<rarila> yep ==  jquery is included in lib.js
<rarila> the extra standalone jqery is for frontend only then
<SahAssar> Yeah, even if they aren't "mixed", I still don't see why we should have the built in option to load jquery.
<gawainlynch> OK … but what ends up where now in HEAD of that branch (jQuery version-wise)
<rarila> SahAssar: won't work in backend anyway
<Bopp> gawainlynch: that's still jquery 2.2.x
<gawainlynch> Ah!
<rarila> question is, is it possible that someone extends the backend and uses jquery functions?
<gawainlynch> OK, so that's not a problem then :-)
<Bopp> in short, I updated NPM, which pulls in jquery 3.1 for our backend, without immediate BC breaks..
<Bopp> the `add_jquery` flag in config.yml still adds jquery 2.2.x to the frontend, if enabled.
<gawainlynch> JS … another freaking galaxy that lot
<gawainlynch> OK, that was my only worry Bopp … if things work, things work :-)
<SahAssar> rarila: The problem is shipping a jquery with bolt explicitly for the frontend and assuming that version works for every extension/theme that enables it.
<Bopp> cool. 
<Bopp> And keep in mind that we can revert it really easy, if anybody has issues with it, during beta. 
<Bopp> but, so far i haven't noticed any
<gawainlynch> Yeah, that part is easy for sure
<gawainlynch> rarilaDroid: JavaScript debug logging
<gawainlynch> Should we add a bolt.log() function, so that we can distinguish between dev only console output and error message like logging
<Bopp> It's not clear to me what we'll gain from that, over console.log.
<phillipp> what would bolt.log() do differently?
<carsonfull> Easier to change/disable?
<gawainlynch> Well, rarila had some points about it … and I think he's been "Princess-ed"
<Bopp> ¯\_(ツ)_/¯ 
<rarila> bolt.log() tells it it is intentional and not just a debug leftover
<SahAssar> Well, it could show more verbose errors in debug mode, and could perhaps be integrated with a #3021 style idea in the future
<carsonfull> I would favor a bolt log that we use internally. 
-[BoltIssueBall]/#boltcms- #3021 [open] [RFC] Knowledge base pages instead of long error messages https://github.com/bolt/bolt/issues/3021 
<rarila> Also we could switch output off when not in debug mode, for example
<phillipp> yeah you convinced me. :D
<Bopp> I'm pretty much neutral on this topic
<gawainlynch> I like the idea of a configurable log like that
<rarila> doe we want to have lines like that at all? https://github.com/bolt/bolt/blob/858d652e49c3b61fef7e0f66f47750a4fe97d766/app/src/js/modules/stack.js#L65
<Bopp> I don't see why not
<phillipp> better than showing nothing and letting the user in the dark
<rarila> Bopp: In production alos or only in a dev mode?
<SahAssar> Bopp: because in production you'd want that to be a simple flash message, while in dev you want more info on why it failed.
<gawainlynch> ^
<carsonfull> FWIW Chrome shows API errors already
<gawainlynch> ^ also
<Bopp> Like I said, i'm fine with either. 
<rarila> phillipp: a normal user won't see them anyway
<carsonfull> If it's for the user, it should be in UI not console
<rarila> carsonfull: my thoughts
<gawainlynch> rarila: All yours mate
<gawainlynch> Anything to raise?
<Bopp> I'm good :-)
<phillipp> just that we have extensions and theme asset recommendations now
<rarila> gawainlynch: how's the Go port coming along?
<phillipp> and i will start to make PRs for all themes and extensions
<gawainlynch> rarila: I keep getting diverted to the Haskell and Python ports
<gawainlynch> SahAssar: All yours
<gawainlynch> …unless you're on your phone :-)
<SahAssar> </meeting>