Welcome to the developer’s discussion channel for the Ceylon programming language. This is where we yell at each other when things are broken again; while it’s a public channel, we consider it more internal than ceylon/user, and won’t control our speech as much here. Enter with caution :)
redhat package name for an independent release we would have to check that with our legal department first :(
That’s too bad. My intention was to help create a backwards compatible release with minimal changes, primarily motivated by the Maven https issue, but also to create a base to (potentially) build on for additional preservation work, such as Java 9+ compatibility.
But, I didn’t realize that a making a compatible release within the Eclipse Foundation was totally out of the question. I’m not interested in forking the project (i.e. new website, branding, etc.), and I’m also not interested (at least for now) in spending time on a compatibility breaking release. IMHO, that would be much less valuable.
We do at least now have a working GitHub Actions build (https://github.com/eclipse/ceylon/actions?query=workflow%3Aintegration-build), so perhaps I’ll add a branch in my GitHub account to build the full 1.3.3 release + maven https url patch. I’m not sure what else there is left for me to do/offer at this point.
There are few other issues labeled with
Breaking changehttps://github.com/eclipse/ceylon/labels/breaking%20change I don't see in most of them the agreement that we wan't them to be included. Only #7409 this I see as includable.
breaking changes into the release, that we agree on. Then in 1.4.x fixes we would just improve what would need to be, as bugs naturally occures. We are trying to give it a fresh start. As for JS, this wild beast need to be tamed somehow. I work in my daily job with Typescript and it's quirky . Kotlin - limited typing. Dart - didn't checked.
I found this thread with Gavin commenting:
Resurrecting a past discussion for a bit, but I actually agree, to some point at least, with what @momomo said back in April:
The best thing this project could do is to strip it bare, to a minimum to maintain
One of the last suggestions I made for the project was that perhaps we had tried to bite of more than we could chew with the CMR, the Ceylon Module Resolver. Yes it could have been really nice if it had all worked out, but IMO it's one of the things that a) sucked up a lot of our time b) was unnecessarily complex (and trying to simplify it would take precious resources away from other important issues) and c) it made interop with Java way more difficult than it needed to be.
My suggestion was to forget about backwards compatibility, create a version 2.0 and mercilessly rip out the CMR part of Ceylon (and I'm saying that as the one who has done the most work on it ;-) ) and just use the native solutions of each platform (Maven artifacts, NPMs, etc). We'd just keep the language, which after all is the nicest part of Ceylon by far.
Now, that didn't mean I wanted to get rid of Ceylon being able to obtain dependencies for compilation/execution automatically, but I was thinking of something much more simple, perhaps a frontend that would make sure all dependencies got downloaded and would be available locally. (In the way JBang https://jbang.dev/ is doing it right now for Java for example).
Anyway, sorry for being late to the party, just wanted to chime in a for a bit ;-)
