Fork me on GitHub

RC4 makes me sad -- we are using serialized-require in our CFML/Clojure bridge in production

Alex Miller (Clojure team)15:12:51

you can still use it - it’s just private


alex giveth, alex taketh away

😂 12
🔥 12
Alex Miller (Clojure team)16:12:03

the goal though is for it to go away

Alex Miller (Clojure team)16:12:13

at which point you can fall back to just require

Alex Miller (Clojure team)16:12:37

the lock is also intentionally public, so you could write the same code and use the same lock if desired

Alex Miller (Clojure team)16:12:32

this is what happens when you ride the lightning Sean :)

😄 4

I suspect the way our CFML/Clojure bridge code works it may already override visibility -- I haven't gotten to my desk yet -- since we call it via the Java API. I was just sad to see it go... 😢


maybe clojure should stop naming releases as alpha/beta/RC ?


I don't think people usually expect breakages going from RC3 to RC4


not that I think this one is going to affect anybody other than Sean :) but for future release cycles




Alex Miller (Clojure team)16:12:25

we are trying to convey something with those names



Alex Miller (Clojure team)16:12:02

but none of them are intended to convey “won’t break”

Alex Miller (Clojure team)16:12:06

alpha = new stuff done, beta = bug fixing, rc = candidate for final release

Alex Miller (Clojure team)16:12:27

this release was a little more fluid than any prior, but stuff happens


oh 1.5 was a lot more fluid than this one :)

Alex Miller (Clojure team)16:12:40

I started working on Clojure at beginning of 1.6 cycle


I understand the meaning they intend to convey in the context of the clojure release cycle, I am not sure that's the general agreed upon meaning of those names though, which may be confusing


reading I get the impression that RC is usually not a phase where stuff gets removed

Alex Miller (Clojure team)16:12:43

well I don’t see how we can control what they mean for other people


but I'm definitely not an expert


picking different names

Alex Miller (Clojure team)16:12:14

I don’t think this is a problem that needs to be solved


fair enough


i'd hate for a wart to be immortalized in a language because it was discovered at RC phase and not at beta. RC seems fair game to remove something to me


> I get the impression that RC is usually not a phase where stuff gets removed this could still be true for clojure; maybe this happening is unusual 🙂

Alex Miller (Clojure team)16:12:17

I would say all changes in an RC are unusual :)

Alex Miller (Clojure team)16:12:22

in that you are “ready for release” but decide a change is important enough to make anyways


Detected Clojure 1.6 or later (API)
Detected cfml-interop for interop
Detected Clojure 1.10 or later (serialized-require)
DI/1 Load Listener using existing cfmljure
That's with RC4 -- we're using the var and resolve parts of the Java API so private is ignored.


Still... RC builds really aren't the place for renaming public functions let alone removing -- and you did both in the RC cycle. I really think you should have gone back to beta and stayed there for a while as this stuff was hammered out.

Alex Miller (Clojure team)16:12:50

what’s the alternative?

Alex Miller (Clojure team)16:12:57

in both cases, we honestly thought we were done - how do you know when you’re really really done enough to make an RC?


The alternatives are: stay in alpha longer or push breaking changes out to the next release. But I understand the trade off, because "no one tests early builds"...

Alex Miller (Clojure team)16:12:47

but how do know when longer is long enough?

Alex Miller (Clojure team)16:12:06

RC is a statement of intent

Alex Miller (Clojure team)16:12:25

all non-official releases are subject to change


You could just go to 1.N.0-preM for release N and montonically increasing M until you actually think you're done.

Alex Miller (Clojure team)16:12:03

but then you lose the intent


This is kind of especially ironic given the value Rich places on accretion and his disparagement of semver etc.

Alex Miller (Clojure team)16:12:27

it’s not ironic at all

Alex Miller (Clojure team)16:12:49

the whole point of having a “dev” period is that you’re allowed to make changes (he specifically talked about this in the speculation talk even)


RC = release candidate.

Alex Miller (Clojure team)16:12:29

alpha means - still making features beta means - done making features, fixing bugs rc means - candidate for release

Alex Miller (Clojure team)16:12:37

going to just numbers obscures that intent

👍 4

All I'm saying is that you put async-require in, folks complained about the name, you said it wasn't up for discussion. It got renamed (potentially breaking new code) in an RC, after telling people the name was "done". Then, after folks were all "yay! thank you for the rename", it got removed in an RC.


Actions here are completely at odds with stated intent.

Alex Miller (Clojure team)17:12:16

imo it’s not at odds with the intent - the intent was to be done in every case. the whole point of doing dev releases is to shake these things out when you’re allowed to be mistaken and make those kinds of changes.


I'm the only person affected by this, I'm pretty sure, and honestly I don't care. I could continue to use the private function, or fall back to require and be no worse off than I was (`serialized-require` actually did solve an edge case bug we have experienced during bootstrapping our app so "Yay!"), and that's why I only brought it up here -- in the "safe space" of the dev list, not in #clojure, not in a thread in #announcements , not on the mailing list.


You went from RC back to beta during this cycle -- which is fine. You could have done this again, or perhaps stayed in beta a bit longer. There's no need to rush the release out if you're genuinely still working on stuff.


And, frankly, I really only brought this up to "tease" about breaking code in an RC... I didn't expect it to be so contentious 😐

Alex Miller (Clojure team)17:12:06

in every case here, we did expect to be done, did not expect to make more changes, and were in no rush.

Alex Miller (Clojure team)17:12:45

that is, we believed in each case that the RC was truly a candidate for release.

Alex Miller (Clojure team)17:12:40

without a time machine, I do not see any way to have made a different decision at each of those points


>You went from RC back to beta during this cycle -- which is fine. You could have done this again I think what Sean was suggesting was RC3 -> beta-whatever -> RC4 instead of RC3 -> RC4

Alex Miller (Clojure team)17:12:36

I don’t understand how that’s effectively different or by what criteria we would have made that decision

Alex Miller (Clojure team)17:12:04

as we did earlier, we did go back to beta when we decided there was more work to do

Alex Miller (Clojure team)17:12:23

in this case, we do not believe there is more work to do

Alex Miller (Clojure team)17:12:34

and there is every chance we will stamp RC4 as GA


OK -- maybe the root of the problem is that it seems like the meaning of alpha/beta/RC cycle assigned by the clojure dev/release process is not what some people expect it to be, is that documented somewhere? if not, I'd be happy to make a ticket about it

Alex Miller (Clojure team)17:12:16

what added benefit would there be in going to beta9, then RC4, then GA?


can I be a bit annoying and ask you to add a line being explicit about nonoe of those guaranteeing no breaking changes? I may be stupid but that's not something that's clearly implied when I read that


unless a critical issue is found -- that definitely implies that during an RC cycle, only "critical issues" will be addressed... renaming async-require to serialized-require and then, later, making it private doesn't seem "critical" to me. So I would say, don't say you'll only make "critical issue" changes in an RC cycle when you don't seem to use that as the criteria internally...


Tending a public API / promises is as critical as it gets

Alex Miller (Clojure team)17:12:12

it seems extremely critical to not release a function we don’t want in the api


I agree with @bronsa here that the guide should clearly state that any and all prerelease builds may have breaking changes (which I know you already agreed with -- just to show we are all in agreement on that point!).


awesome, thanks

Alex Miller (Clojure team)17:12:54

btw, I have been moving stuff from the old community wiki to the public site this week


is confluence effectively abandoned now then?


I was about to ask that too 🙂


or is this just for the "guides" part of confluence

Alex Miller (Clojure team)17:12:56

I’d say it is increasingly less relevant :)


There's some old stuff there about Contrib -- spread across multiple pages -- that probably ought to be curated into something up-to-date... or simply removed perhaps?


I won't shed any tears about that

Alex Miller (Clojure team)17:12:48

I’m working on moving all the stuff that I think is useful from the community wiki to the web site

👍 4

Good work, thank you!

Alex Miller (Clojure team)17:12:23

I have deleted a couple things, marked some as deprecated, left some as is

Alex Miller (Clojure team)17:12:08

mostly focusing on the dev stuff, may leave the contrib stuff for now, but may ultimately move those elsewhere


there's some pages in that confluence that are quite historically interesting, with discussions/comments about how certain features have been designed

👍 4

I assume those are not going to get removed?

Alex Miller (Clojure team)17:12:54

that’s all the design space

Alex Miller (Clojure team)17:12:01

not touching that for now

Alex Miller (Clojure team)17:12:28

the three big spaces are design (leaving), doc (largely dead and way out of date), and community (which I am trying to migrate)

Alex Miller (Clojure team)17:12:38

we also want to add some new up front material that is more about how people can help and work with us in the best possible way (and we are considering some new ideas about that)

👍 8
Alex Miller (Clojure team)17:12:50

but that’s probably slightly farther off

Alex Miller (Clojure team)17:12:58

I merged a bunch of site prs yesterday too, including Andy’s equality guide


Thanks. I plan to do a double-check of that after 1.10 is finalized, and if nothing has changed, as I expect it won't, will submit a PR updating the "describes the behavior of Clojure 1.9.0" line to 1.10.0 if everything still checks out.

Alex Miller (Clojure team)18:12:03

I did update all the NaN refs to ##NaN

Alex Miller (Clojure team)18:12:17

at my reading, nothing else to change afaik