Arduino IDE is packaged for Windows in multiple formats:
- ZIP
- NSIS
- Windows Installer (AKA "MSI")
The interactive installer of the NSIS package makes it the best option for installation by users.
The other use case for the installers is deployment by a system administrator. The Windows Installer package was added
to offer an additional installer option for this specific use case.
In this use case, a "silent install" will often be required. Previously, the Windows Installer package was configured to
start the Arduino IDE after completing the installation. This behavior is likely to be problematic for the very use case
the Windows Installer package was intended for. That configuration was not intentional, but rather a result of using
whatever setting electron-builder happened to provide as a default.
The behavior of the Windows Installer package is hereby changed to not run after installation. This also aligns it with
the behavior of the NSIS package's silent installation (running the installer with the `/S` flag).
The behavior of the NSIS installer is unchanged:
- When in interactive mode: user chooses whether to start Arduino IDE
- When in silent mode: Arduino IDE does not start after installation
* add notes for Windows contributor in BUILDING.md
* rephrase notes for Windows contributor in BUILDING.md
* Update notes for Windows contributor in BUILDING.md
Co-authored-by: per1234 <accounts@perglass.com>
* move Notes for Windows contributors in Build from source section
Co-authored-by: per1234 <accounts@perglass.com>
This project provides the contributors with templates for the fundamental categories of issues:
- bug report
- feature request
This is helpful to the maintainers and developers because it establishes a standardized framework for the issues and
encourages the contributors to provide the essential information.
GitHub's original issue template system is very crude, simply pre-populating the issue description field with the text
from the template file.
https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository#creating-issue-templates
The contributor may be confused by being presented with a mass of Markdown and placeholder
content where they expected a field to write their issue. They also may find it inconvenient to manuever around the
framework content and replace the placeholder content.
A far better system is now available with GitHub's recently introduced form-based issue templates:
https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository#creating-issue-forms
The user is now presented with a web form. These may include multi-line input fields that have the same formatting and
attachment capabilities as the standard GitHub Issue composer, but also additional elements such as menus and checkboxes.
The use of this form-based system should provide a much better experience for the contributors and also result in higher
quality issues.
The automatically created issue template chooser provides a menu of links to the available issue report templates as
well as the security policy at the start of the issue creation process.
It is also possible to add additional arbitrary items to the chooser, through GitHub's "Contact Links" feature. These
are defined in a configuration file:
https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository#configuring-the-template-chooser
These links offer the possibility to redirect support requests and other sub-optimal usages of the issues to the
appropriate location. This benefits the user by providing them with a fast and frictionless path to what they need, and
benefits the maintainers by preventing inappropriate issues.
When using the interactive installer, the user is presented with a dialog requested they agree to this.
The previous statement about initiation of a download constituting agreement is relevant in the context of the text's source on the arduino.cc downloads page, but not at all in the context of the installer dialog.
Linux x86-64 builds of the Arduino IDE are now available in AppImage format in additional to the ZIP format.
Since only the AppImage format IDE supports auto-updates (the IDE installed from the ZIP will notify of available updates, but can't auto-update), this will be the preferred format and so good beta testing coverage of it is especially important.
The "Compose full changelog" GitHub Actions workflow generates a changelog file from the release notes and uploads this
to Arduino's server for display to the user by the IDE updater.
Previously, this workflow could be triggered by either of two events:
- Release creation
- Release edit
To reduce the possibility of endless recursion, GitHub Actions ignores events which are triggered using the
auto-generated `GITHUB_TOKEN` access token. All release creations are done automatically by the "Arduino IDE" GitHub
Actions workflow, which uses this token.
For this reason, the release creation trigger will never be used. Since the behavior of the event being ignored by
GitHub Actions under these conditions is not at all obvious, having the workflow configured for such an irrelevant
trigger can cause confusion.
The workflow will be triggered by the manual edit which is done on every release to format the raw release notes
auto-generated from the commit history. So the fact that the release creation trigger doesn't work is not a problem.
* IDE updater assorted bugfix
- add linux AppImage target
- fix hardcoded if condition that causes to always show the update dialog
- fix redundant test build version
- recalculate sha512 after notarization on macOS
* boost notarization speed
* recalculate artifacts hash
* Remove check for updates on startup setting
* Remove useless exported function
* Update template-package.json used to package IDE
* Add function to get channel file during packaging step
* Add updates check
* move ide updater on backend
* configure updater options
* add auto update preferences
* TMP check updates on start and download
* index on check-update-startup: fcb8f6e TMP check updates on start and download
* set version to skip on local storage
* add IDE setting to toggle update check on start-up
* comment out check for updates on startup and auto update settings
* Update Theia to 1.22.1
* updated CI
* download changelog and show it in IDE updater dialog
* remove useless file
* remove useless code
* add i18n to updater dialog
* fix i18n
* refactor UpdateInfo typing
* add macos zip to artifacts
* Simply use `--ignore-engines`
* Use correct --ignore-engines
* Fix semver#valid call
* Use C++17
* updated documentation
* add update channel preference
* update updater url
* updated documentation
* Fix the C++ version
* Build flag for cpp
* add disclaimer with correct node version
* Update `electron-builder`
* Fix `Electron.Menu` issue
* Skip electron rebuild
* Rebuild native dependencies beforehand
* Use resolutions section
* Update template-package.json as well
* move ide-updater to electron application
* refactor ide-updater service
* update yarn.lock
* update i18n
* Revert "Add gRPC user agent (#834)"
This reverts commit 5ab3a747a6e8bf551b5c0e59a98154d387e0a200.
* fix ide download url
* update latest file in CI
* fix i18n check
Co-authored-by: Silvano Cerza <silvanocerza@gmail.com>
Co-authored-by: Francesco Stasi <f.stasi@me.com>
Co-authored-by: Mark Sujew <msujew@yahoo.de>
