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.


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


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


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


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.


the point is arbitrary


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


but there is always another release


by doing these more frequently, hopefully the wait is shorter between arbitrary points


these == releases


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 your pain


as I am in the same boat


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


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


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


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)


*Burden I meant


I assumed :)


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.


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?


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


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.