Roadmap Process

[artf]

Hi folks, welcome to the GrapesJS Roadmap discussion.

Here you can find the actual GrapesJS Roadmap project.

Here I'd like to explain what is the long-term vision GrapesJS is aiming for and how the Roadmap process is expected to work in order to help us reach our goals.

Goals

• GrapesJS is a framework for building web-based editors, not an end-user application.
  • It's up to the consumer to create the "user-friendly UI" of the editor.
  • As a framework, our goal is to provide the ability the replace the default UI, if one exists.
• The core should be as lean as possible.
  • Provide only strictly necessary functionalities that could be used across different application domains.
• The core should be as headless as possible.
  • You don't need UI components if you're running GrapesJS server-side
• The core should be extendable.
  • It should be possible to add new functionalities or extend the existing ones.

The process

Here it's explained how the GrapesJS Roadmap process works and what are the necessary steps required to bring your suggestions into the project.

The Roadmap process, at a high level, is divided into two parts, the first one is the Roadmap Suggestions discussion category, which will be used to collect and vote for new suggestions from the community, and then there is the Roadmap Project which will provide the status of the accepted suggestion.

From suggestion to production

1. Open a new discussion in the Roadmap Suggestions category.

   • Specify, in the title, the type of suggestion you'd like to bring in:
     • Feature Request, title: [Feature]: ....
     • Plugin Request, title: [Plugin]: ....
     • Documentation to add/improve, title: [Docs]: ....
     • WARNING: no bugs, those are already handled in the Bug report from GitHub Issues
   • Describe your suggestion as much in detail as possible.

2. Now people can comment and vote on the suggestion before bringing it into the Roadmap.

   • Use the default voting mechanism provided by GitHub Discussions.
     

3. The suggestion should reach at least 15 votes before being evaluated and accepted for the Roadmap.

4. Once the suggestion reached the minimal amount of votes, it will be evaluated and moved into the Roadmap.

5. The suggestion can now start its development cycle.

   • Accepted: here we can discuss all the necessary information in order to start working on the suggestion.
   • In progress: the suggestion is in development.
   • In review: a PR is opened for the suggestion and it's in the review process.
   • Done: the suggestion is now merged and will be available in the next release.

If you have any questions/suggestions about the Roadmap process, you can post them directly here in this discussion post.

[lexoyo]

Great thank you @artf that's very clear and in the free software spirit

Concerning breaking changes / versions, do you have a process or vision ? As a framework it is important that it is a good balance between go fast and don't break applications too often ;)

Thank you for this, your leadership is inspiring

[artf]

Thank you @lexoyo I don't have yet a clear process of versioning, besides switching to a real semantic versioning one day, we're still in v0.* stage where breaking changes are indicated via minor updates.

At the current state, we're a bit far from the designed goals (eg. a lot of stuff has to be moved away from the core), and the closer we get there means the introduction of breaking changes.

[tahsin352]

when v0.* will become v1? do we have any plan for stable release?

[artf]

Do not have a plan yet to switch to v1.*, probably the package name itself will be moved to a new name (eg. @grapesjs/core)

[luisalvarado]

Thank yo so much for the information artf.

[awesome1128]

Can I know how to use this library in Laravel v10?
Please let me know, thanks

[artf]

Please @awesome1128 don't be that guy, avoid posting off-topic questions here

[ronaldohoch]

Thank you @artf 👏