You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Iteration 6 triggered various infrastructure topics which absorbed us so much that we decided to extend this iteration until the end of January. This could be a nice way of saying that we have a delay ;), but the changes that we have made and on which we are still working are really significant and could only be done before we release CKEditor 5 and could not be split into multiple iterations. Let's start from the beginning.
Project infrastructure
We are getting closer and closer to the final release, so it is high time to re-evaluate architectural decisions which we have taken earlier. This is especially important for the project infrastructure because all the software (which includes the official packages as well as 3rd party ones) is built upon it. Some of the topics which we (re)opened were:
Compilation was a building step performed before bundling CKEditor which was meant to encapsulate all CKEditor-specific tasks so CKEditor could be later bundled using any bundler of one's choice. This was a noble idea but turned to be really inconvenient and complicate things instead of simplifying them. We decided to get rid of the compilation step by aligning our building process as much as possible to the "JS standard(s)" (like there is only one) and encapsulate the remaining things (such as language files compilation) in plugins prepared for existing bundlers.
Even now, the change required a lot of work, but we have already seen that it makes it a lot easier to integrate building CKEditor with your workflow.
After settling on the building without compilation, we turned our faces towards switching to scoped packages and versioned dependencies. So far, we have been using npm to install dependencies from GitHub by using GitHub URLs in package.json. We need to stop doing this and use proper versioned dependencies. We also want to have all the official packages scoped in @ckeditor. This meant that we needed to review all our existing dev tools. We took that chance and proposed a simple (and generic) tool called mgit2. It allows to manage multi-repo projects and together with Lerna make a perfect pair for multi-repo multi-package projects.
We are now working on integrating mgit2 into our Travis setup. Once this is done, CKEditor 5 will be super easy to integrate, work with and develop.
Other changes
After this lengthy introduction about infrastructure I will just list some of the other things that we worked on because, besides infrastructure, we are also constantly pushing forward features and improvements for CKEditor 5 itself.
Release tools are under development. They include automatic changelog generation, automated semantic version bumping (based on the changelog) and synchronising dependency versions.
The paragraph feature's converter behaves like a wildcard now, which is important for handling pasting content that contains markup with no existing converters.
It's the first News and Updates issue since the end of November which closed iteration 5.
Iteration 6 triggered various infrastructure topics which absorbed us so much that we decided to extend this iteration until the end of January. This could be a nice way of saying that we have a delay ;), but the changes that we have made and on which we are still working are really significant and could only be done before we release CKEditor 5 and could not be split into multiple iterations. Let's start from the beginning.
Project infrastructure
We are getting closer and closer to the final release, so it is high time to re-evaluate architectural decisions which we have taken earlier. This is especially important for the project infrastructure because all the software (which includes the official packages as well as 3rd party ones) is built upon it. Some of the topics which we (re)opened were:
However, the two most influential issues turned out to be a question whether we need the compilation step and how to switch to scoped packages and versioned dependencies.
Compilation was a building step performed before bundling CKEditor which was meant to encapsulate all CKEditor-specific tasks so CKEditor could be later bundled using any bundler of one's choice. This was a noble idea but turned to be really inconvenient and complicate things instead of simplifying them. We decided to get rid of the compilation step by aligning our building process as much as possible to the "JS standard(s)" (like there is only one) and encapsulate the remaining things (such as language files compilation) in plugins prepared for existing bundlers.
Even now, the change required a lot of work, but we have already seen that it makes it a lot easier to integrate building CKEditor with your workflow.
After settling on the building without compilation, we turned our faces towards switching to scoped packages and versioned dependencies. So far, we have been using npm to install dependencies from GitHub by using GitHub URLs in
package.json
. We need to stop doing this and use proper versioned dependencies. We also want to have all the official packages scoped in@ckeditor
. This meant that we needed to review all our existing dev tools. We took that chance and proposed a simple (and generic) tool called mgit2. It allows to manage multi-repo projects and together with Lerna make a perfect pair for multi-repo multi-package projects.We are now working on integrating mgit2 into our Travis setup. Once this is done, CKEditor 5 will be super easy to integrate, work with and develop.
Other changes
After this lengthy introduction about infrastructure I will just list some of the other things that we worked on because, besides infrastructure, we are also constantly pushing forward features and improvements for CKEditor 5 itself.
BalloonPanelView
to enable code reuse.The text was updated successfully, but these errors were encountered: