@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: https://groups.google.com/forum/#!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

cool - that's this bug? http://dev.clojure.org/jira/browse/ASYNC-149

did you get the latest core.memoize update 0.5.8?

@alexmiller: yes to both

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

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?

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