RC4 makes me sad -- we are using serialized-require in our CFML/Clojure bridge in production https://clojurians.slack.com/archives/C06MAR553/p1544194150067500

you can still use it - it’s just private

alex giveth, alex taketh away

the goal though is for it to go away

at which point you can fall back to just require

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

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

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

pour one out…

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

1.11.dev-15

¯\(ツ)/¯

we are trying to convey something with those names

1.11.almost-there-25

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

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

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

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

before my time :)

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 https://en.wikipedia.org/wiki/Software_release_life_cycle#Release_candidate I get the impression that RC is usually not a phase where stuff gets removed

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

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 🙂

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

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

gotcha

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.

what’s the alternative?

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

but how do know when longer is long enough?

RC is a statement of intent

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.

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.

it’s not ironic at all

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.

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

going to just numbers obscures that intent

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.

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 😐

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

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

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

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

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

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

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

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

I don’t think so. I will add one now to https://clojure.org/community/devchangelog

thanks

https://github.com/clojure/clojure-site/commit/042de43dac8a1068602acbe9a087a356d943ce41

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

sure

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

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

so, disagree

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

added

awesome, thanks

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

Excellent!

is confluence effectively abandoned now then?

https://clojure.org/community/workflow https://clojure.org/community/creating_tickets https://clojure.org/community/developing_patches https://clojure.org/guides/faq#_contributing

I was about to ask that too 🙂

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

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

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

Good work, thank you!

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

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

I assume those are not going to get removed?

that’s all the design space

not touching that for now

cool

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

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)

but that’s probably slightly farther off

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