Fork me on GitHub
#clojure-dev
<
2018-12-07
>
seancorfield15:12:13

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

alexmiller15:12:51

you can still use it - it’s just private

bronsa16:12:01

alex giveth, alex taketh away

😂 3
🔥 3
alexmiller16:12:03

the goal though is for it to go away

alexmiller16:12:13

at which point you can fall back to just require

alexmiller16:12:37

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

alexmiller16:12:32

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

😄 1
1
seancorfield16:12:34

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

alexmiller16:12:18

pour one out…

bronsa16:12:07

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

bronsa16:12:32

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

bronsa16:12:27

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

bronsa16:12:12

1.11.dev-15

bronsa16:12:22

¯\(ツ)

alexmiller16:12:25

we are trying to convey something with those names

bronsa16:12:38

1.11.almost-there-25

alexmiller16:12:02

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

alexmiller16:12:06

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

alexmiller16:12:27

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

bronsa16:12:04

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

alexmiller16:12:12

before my time :)

alexmiller16:12:40

I started working on Clojure at beginning of 1.6 cycle

bronsa16:12:13

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

bronsa16:12:34

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

alexmiller16:12:43

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

bronsa16:12:43

but I'm definitely not an expert

bronsa16:12:01

picking different names

alexmiller16:12:14

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

bronsa16:12:17

fair enough

dpsutton16:12:38

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

gfredericks16:12:30

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

alexmiller16:12:17

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

alexmiller16:12:22

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

seancorfield16:12:04

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.

seancorfield16:12:01

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.

alexmiller16:12:50

what’s the alternative?

alexmiller16: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?

seancorfield16:12:36

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

alexmiller16:12:47

but how do know when longer is long enough?

alexmiller16:12:06

RC is a statement of intent

alexmiller16:12:25

all non-official releases are subject to change

seancorfield16:12:47

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

alexmiller16:12:03

but then you lose the intent

seancorfield16:12:17

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

alexmiller16:12:27

it’s not ironic at all

alexmiller16: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)

dpsutton16:12:58

RC = release candidate.

1
alexmiller16:12:29

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

alexmiller16:12:37

going to just numbers obscures that intent

👍 1
seancorfield16:12:11

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.

seancorfield16:12:24

Actions here are completely at odds with stated intent.

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

seancorfield16:12:16

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.

seancorfield16:12:24

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.

seancorfield16:12:00

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 😐

alexmiller17:12:06

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

alexmiller17:12:45

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

alexmiller17:12:40

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

bronsa17:12:55

>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

alexmiller17:12:36

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

alexmiller17:12:04

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

alexmiller17:12:23

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

alexmiller17:12:34

and there is every chance we will stamp RC4 as GA

bronsa17:12:10

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

alexmiller17:12:16

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

alexmiller17:12:48

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

bronsa17:12:53

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

seancorfield17:12:43

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

ghadi17:12:50

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

alexmiller17:12:12

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

alexmiller17:12:20

so, disagree

seancorfield17:12:58

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

bronsa17:12:42

awesome, thanks

alexmiller17:12:54

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

bronsa17:12:29

is confluence effectively abandoned now then?

seancorfield17:12:41

I was about to ask that too 🙂

bronsa17:12:48

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

alexmiller17:12:56

I’d say it is increasingly less relevant :)

seancorfield17:12:22

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?

bronsa17:12:28

I won't shed any tears about that

alexmiller17:12:48

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

👍 1
seancorfield17:12:59

Good work, thank you!

alexmiller17:12:23

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

alexmiller17:12:08

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

bronsa17:12:45

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

👍 1
bronsa17:12:51

I assume those are not going to get removed?

alexmiller17:12:54

that’s all the design space

alexmiller17:12:01

not touching that for now

alexmiller17: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)

alexmiller17: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)

👍 2
alexmiller17:12:50

but that’s probably slightly farther off

alexmiller17:12:58

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

andy.fingerhut17:12:29

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.

alexmiller18:12:03

I did update all the NaN refs to ##NaN

alexmiller18:12:17

at my reading, nothing else to change afaik