6e18dca644
Previously, releases were always made from a point in the revision history of the `main` branch (typically the tip of the branch at the time of the release). Although the simplicity of this approach is nice, it can be limiting in some cases. For this reason, the project is switching to using a "trunk-based" development strategy, as described here: https://trunkbaseddevelopment.com/ This approach allows making releases at any time that consist of the arbitrary subset of revisions suitable for shipping to the users at that time. The commits that should be included in the release are cherry-picked to a release branch and the tag created on that branch. This means that: - PRs can be merged to the `main` branch as soon as they have passed review rather than having to postpone the merge of changes that are not ready to be included in the next release. - Releases don't need to be postponed if the prior revision history on the `main` branch contains changes that are not ready to be included in the release. The documented release procedure must be adjusted to reflect the new development strategy. CI System Adjustments --------------------- The status of the GitHub Actions workflows should be evaluated before making a release. However, this is not so simple as checking the status of the commit at the tip of the release branch. The reason is that, for the sake of efficiency, the workflows are configured to run only when the processes are relevant to the trigger event (e.g., no need to run unit tests for a change to the readme). In the case of the default branch, you can simply set the workflow runs filter to that branch and then check the result of the latest run of each workflow of interest. However, that was not possible to do with the release branch since it might be that the workflow was never run in that branch. The status of the latest run of the workflow in the default branch might not match the status for the release branch if the release branch does not contain the full history. For this reason, it will be helpful to trigger all relevant workflows on the creation of a release branch. This will ensure that each of those workflows will always have at least one run in the release branch. Subsequent commits pushed to the branch can run based on their usual trigger filters and the status of the latest run of each workflow in the branch will provide an accurate indication of the state of that branch. Branches are created for purposes other than releases, most notably feature branches to stage work for a pull request. Due to the comprehensive nature of this project's CI system, it would not be convenient or efficient to fully run all CI workflows on the creation of every feature branch. Unfortunately, GitHub Actions does not support filters on the `create` event of branch creation like it does for the `push` and `pull_request` events. There is support for a `branches` filter of the `push` event, but that filter is an "AND" to the `paths` filter while this application requires an "OR". For this reason, the workflows must be triggered by the creation of any branch. The unwanted job runs are prevented by adding a `run-determination` job with the branch filter handled by Bash commands. The other jobs of the workflow use this `run-determination` job as a dependency, only running when it indicates they should via a job output. Because this minimal `run-determination` job runs very quickly, it is roughly equivalent to the workflow having been skipped entirely for non-release branch creations.
Arduino IDE 2.x
This repository contains the source code of the Arduino IDE 2.x. If you're looking for the old IDE, go to the repository of the 1.x version at https://github.com/arduino/Arduino.
The Arduino IDE 2.x is a major rewrite, sharing no code with the IDE 1.x. It is based on the Theia IDE framework and built with Electron. The backend operations such as compilation and uploading are offloaded to an arduino-cli instance running in daemon mode. This new IDE was developed with the goal of preserving the same interface and user experience of the previous major version in order to provide a frictionless upgrade.
Download
You can download the latest release version and nightly builds from the software download page on the Arduino website.
Support
If you need assistance, see the Help Center and browse the forum.
Bugs & Issues
If you want to report an issue, you can submit it to the issue tracker of this repository.
See the issue report guide for instructions.
Security
If you think you found a vulnerability or other security-related bug in this project, please read our security policy and report the bug to our Security Team 🛡️ Thank you!
e-mail contact: security@arduino.cc
Contributions and development
Contributions are very welcome! There are several ways to participate in this project, including:
- Fixing bugs
- Beta testing
- Translation
See the contributor guide for more information.
See the development guide for a technical overview of the application and instructions for building the code.
Donations
This open source code was written by the Arduino team and is maintained on a daily basis with the help of the community. We invest a considerable amount of time in development, testing and optimization. Please consider donating or sponsoring to support our work, as well as buying original Arduino boards which is the best way to make sure our effort can continue in the long term.
License
The code contained in this repository and the executable distributions are licensed under the terms of the GNU AGPLv3. The executable distributions contain third-party code licensed under other compatible licenses such as GPLv2, MIT and BSD-3. If you have questions about licensing please contact us at license@arduino.cc.