Fork me on GitHub

@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.

Alex Miller (Clojure team)02:11:48

well I'd look at them :)


@alexmiller: I'm releasing tools.analyzer.jvm with a bugfix for the core async bug reported here:!msg/clojure/NdQMUs1mTUU/_-K_CJSuBQAJ


also bumping core.memoize and tools.reader deps


probably worth cutting a core async release using the fixed t.a.jvm version aswell

Alex Miller (Clojure team)14:11:38

did you get the latest core.memoize update 0.5.8?


Is it intentional that clojure.lang.Tuple is still active in several codepaths?


I can file a ticket if not.


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


@ghadi: Tuple/create just returns a PV


thanks, nicola

bronsa19:11:30 this video nicely sums up how I feel everytime a ticket's "Fix Version" gets bumped

Alex Miller (Clojure team)19:11:41

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?


I understand pushing back features if there's no time to invest on them


but pushing back on serious bugfixes where the work of fixing them has already been done, that I really don't understand

Alex Miller (Clojure team)19:11:53

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

Alex Miller (Clojure team)19:11:37

changing things (anything) introduces more possibilities for interactions. at some point, you stop changing things and wait for a while. then release.

Alex Miller (Clojure team)19:11:15

when your patch is on the other side, it seems capricious

Alex Miller (Clojure team)19:11:26

but there is always another release

Alex Miller (Clojure team)19:11:47

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

Alex Miller (Clojure team)19:11:59

as I am in the same boat


I'm talking about myself here, but I'm sure other contributors understand it aswell

Alex Miller (Clojure team)19:11:15

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

Alex Miller (Clojure team)19:11:28

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 simple_smile 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.

Alex Miller (Clojure team)19:11:27

I could just go close a bunch of tickets if you like :)

Alex Miller (Clojure team)19:11:08

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

Alex Miller (Clojure team)20:11:28

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.

Alex Miller (Clojure team)20:11:52

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)


*Burden I meant


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

Alex Miller (Clojure team)21:11:35

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.

Alex Miller (Clojure team)21:11:11

but I've been in that situation at commercial s/w companies


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?

Alex Miller (Clojure team)21:11:04

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

Alex Miller (Clojure team)21:11:35

we've done a good enough job with maintaining compatibility that neither has been very problematic as far as I've heard

Alex Miller (Clojure team)21:11:19

Cognitect does sell Clojure support as well but I can't recall running into an issue related to this through support


Now that is pretty awesome. Having a clean and working upgrade path is better than supporting all that versions. This is something webmethods is clearly lacking. Upgrading is like a 1000-class citizen for us.