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 :)
Resolve concerns with use of the *.redhat.com package namespace where necessary to maintain backwards compatibility. Most of the necessary usage is internal, but may be exposed to end users in some cases.
Resolve (possible) IP concerns with unwanted commits that are present in the "root" Eclipse foundation commit. Technical challenges remain, but we can perhaps a) build a new branch by cherry-picking commits we want to keep, or b) accept the current "root", and revert commits we don't want to keep. There are technical downsides to both (e.g. difficulty of revert pre-rename commits, difficulty of future inclusion of currently unwanted commits).
Determine TODO list of items necessary for an initial release to be made (IP, website, infrastructure, governance, etc.)
git config diff.renames truegit config diff.renamelimit 0It finds renamed files and tries to merge them rather than subjecting old ones to be deleted and new ones as added
more into this here: https://stackoverflow.com/questions/22582605/git-merge-branches-with-different-directory-structures
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.
