This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # alda (28)
- # announcements (7)
- # beginners (79)
- # boot (62)
- # cider (11)
- # cljsjs (12)
- # cljsrn (8)
- # clojure (111)
- # clojure-art (2)
- # clojure-austin (5)
- # clojure-conj (3)
- # clojure-dev (54)
- # clojure-japan (12)
- # clojure-russia (30)
- # clojurescript (354)
- # clojurex (5)
- # cursive (9)
- # data-science (58)
- # datomic (19)
- # editors-rus (3)
- # emacs (7)
- # events (2)
- # hoplon (5)
- # ldnclj (6)
- # lein-figwheel (14)
- # luminus (1)
- # off-topic (10)
- # om (191)
- # onyx (59)
- # re-frame (30)
- # reagent (74)
- # robots (1)
- # yada (19)
@bronsa: Sure, will get to that some time in the next week or three. Would be nice to include some more expressions like those Alex Miller has been reporting in some of the CLJ JIRA tickets to evaluate changes, although doing all of those would probably be more than anyone would want to look at.
@alexmiller: I'm releasing tools.analyzer.jvm with a bugfix for the core async bug reported here: https://groups.google.com/forum/#!msg/clojure/NdQMUs1mTUU/_-K_CJSuBQAJ
Since a reason for it being removed was that it polluted dispatch caches, then we should make sure that it isn't active at all
https://www.youtube.com/watch?v=-z0Pm7tccvc this video nicely sums up how I feel everytime a ticket's "Fix Version" gets bumped
the rules are about the same as every commercial software project I've worked on in the last 20 years. what is surprising to you?
but pushing back on serious bugfixes where the work of fixing them has already been done, that I really don't understand
there are an arbitrary amount of bugs with fixes in a variety of states at all times
but it's the same issue that has been raised to death already, really not much value in arguing about it
changing things (anything) introduces more possibilities for interactions. at some point, you stop changing things and wait for a while. then release.
by doing these more frequently, hopefully the wait is shorter between arbitrary points
but there is always maintenance that has to happen on (my) side to keep the work up to date
which is often a long time after the original work has been done. mental context is lost and I have to waste even more time to understand it again
I feel like there were both a large number of older tickets with reasonable patches and some higher voted/priority tickets that we were able to shepherd through the process in a comparatively short release this time
the number of non-feature related tickets was about the same for 1.7 vs 1.8 but with a significantly shorter timespan
the net increase in the number of closed tickets wasn't that much though. went from 69% to 71%
don't get me wrong, I'm happy that we got this amount of tickets closed in this short period of time, I just don't think it's nearly enough
and please don't think I'm bitter about any of my tickets specifically not getting in. For any one of the tickets I've worked on I could name one I haven't that I'd rather be included
@bronsa: Might be time to add a new hobby to your list Seriously, though, one is always subject to the decisions of a project's deciding person/people, when submitting proposed changes to that project. Clojure is no different there than any other.
I once had a manager that came in and closed all tickets more than 6 months old (without looking at them) - "they'll come back if they're important"
we are about to switch back from a 6 month release cycle to 12. Having to support every release puts an enourmous burden on every one of our teams plus the guys managing the old releases, it just becomes to much
is that a comment about Clojure's release cycle or just a general release management comment?
@alexmiller: Just a general comment. I don't know enough about the clojure release management to make statements of it. Just wanted to say that support for old versions can become a burned fast.
can you say more? just trying to understand the pain point. do you need to support every new clojure release? if so, why? (external users, library upgrades force you to, etc)
Sorry, this was not clojure specific. We have a product (webMethods, not sure if you heard of it). Consisting of like 50 sub products and we support 5 + 2 years, meaning maximum 14 releases. So every product team has to support up to 14 releases. My point is, doubling the release cycle can also double/triple/... the cost
gotcha (and yes I've heard of webmethods :) - since we don't typically do maintenance releases of old Clojure versions, this has not (to date) been an issue.
That's why there was no 1.x.x release yet. I always wondered how it worked out. Seems like that's not a problem yet. I wonder if this might change if "big" corporations start using clojure with fixed versions. Did you ever think of that possibility? Or are you (you as cognitect) just waiting for it to happen?
so far, most companies either stick with a version for a multi-year period, then update as part of their normal dev OR update along with the new releases
we've done a good enough job with maintaining compatibility that neither has been very problematic as far as I've heard
Cognitect does sell Clojure support as well but I can't recall running into an issue related to this through support