This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # adventofcode (202)
- # aleph (8)
- # announcements (13)
- # architecture (1)
- # aws (2)
- # beginners (201)
- # boot (1)
- # bristol-clojurians (1)
- # calva (2)
- # cider (23)
- # cljs-dev (22)
- # cljsrn (2)
- # clojure (105)
- # clojure-bangladesh (1)
- # clojure-berlin (8)
- # clojure-dev (104)
- # clojure-europe (3)
- # clojure-italy (5)
- # clojure-losangeles (1)
- # clojure-nl (24)
- # clojure-russia (55)
- # clojure-spec (44)
- # clojure-uk (19)
- # clojurescript (58)
- # component (58)
- # cursive (3)
- # data-science (1)
- # datomic (27)
- # duct (6)
- # events (6)
- # figwheel-main (6)
- # fulcro (15)
- # jobs (3)
- # kaocha (5)
- # luminus (1)
- # music (1)
- # nrepl (2)
- # off-topic (24)
- # onyx (1)
- # pedestal (3)
- # protorepl (8)
- # re-frame (18)
- # reagent (39)
- # reitit (1)
- # remote-jobs (1)
- # ring (15)
- # rum (11)
- # shadow-cljs (5)
- # sql (8)
- # tools-deps (12)
- # vim (7)
RC4 makes me sad -- we are using
serialized-require in our CFML/Clojure bridge in production https://clojurians.slack.com/archives/C06MAR553/p1544194150067500
the lock is also intentionally public, so you could write the same code and use the same lock if desired
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... 😢
not that I think this one is going to affect anybody other than Sean :) but for future release cycles
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
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 🙂
in that you are “ready for release” but decide a change is important enough to make anyways
That's with RC4 -- we're using the
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
resolveparts 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.
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"...
You could just go to 1.N.0-preM for release N and montonically increasing M until you actually think you're done.
This is kind of especially ironic given the value Rich places on accretion and his disparagement of semver etc.
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)
alpha means - still making features beta means - done making features, fixing bugs rc means - candidate for release
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.
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 😐
in every case here, we did expect to be done, did not expect to make more changes, and were in no rush.
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
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
I don’t think so. I will add one now to https://clojure.org/community/devchangelog
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
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...
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!).
btw, I have been moving stuff from the old community wiki to the public site this week
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’m working on moving all the stuff that I think is useful from the community wiki to the web site
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
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)
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.