├── LICENSE.md ├── README.md ├── TEMPLATE.md ├── electron-update-procedure.md └── unofficial-atom-distributions.md /LICENSE.md: -------------------------------------------------------------------------------- 1 | Copyright (c) 2016 GitHub Inc. 2 | 3 | Permission is hereby granted, free of charge, to any person obtaining a copy 4 | of this software and associated documentation files (the "Software"), to deal 5 | in the Software without restriction, including without limitation the rights 6 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 7 | copies of the Software, and to permit persons to whom the Software is 8 | furnished to do so, subject to the following conditions: 9 | 10 | The above copyright notice and this permission notice shall be included in all 11 | copies or substantial portions of the Software. 12 | 13 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 14 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 15 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 16 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 17 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 18 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 19 | SOFTWARE. 20 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | ##### Atom and all repositories under Atom will be archived on December 15, 2022. Learn more in our [official announcement](https://github.blog/2022-06-08-sunsetting-atom/) 2 | # Design Decisions 3 | 4 | A place to document various Atom project design decisions for public reference. 5 | 6 | ## Process - Public Discussion 7 | 8 | 1. Create a pull request by filling out the [template](TEMPLATE.md) and saving it under a unique name. 9 | 1. Discuss 10 | 1. Document arguments for and against 11 | 1. Document the decision 12 | 1. Merge the pull request 13 | 14 | ## Process - Documenting Current Policy 15 | 16 | 1. Write it up 17 | 1. Post it 18 | -------------------------------------------------------------------------------- /TEMPLATE.md: -------------------------------------------------------------------------------- 1 | # Title 2 | 3 | **Question:** Problem statement formed as a question 4 | 5 | Detailed description of the problem 6 | 7 | * Examples 8 | * Examples supporting the affirmative 9 | * Counter-examples 10 | * Examples supporting the negative 11 | 12 | ## Arguments For 13 | 14 | ## Arguments Against 15 | 16 | ## Decision 17 | 18 | TBD 19 | -------------------------------------------------------------------------------- /electron-update-procedure.md: -------------------------------------------------------------------------------- 1 | # Electron Update Procedure 2 | 3 | **Question:** How do we decide when to update to a new version of Electron? How do we update Atom from one version of Electron to the next? How can external contributors help? 4 | 5 | ## Decision Process 6 | 7 | We decide to update to a new version of Electron when there is an enhancement or bug fix that version would enable that would benefit Atom users. Because updating to a new version of Electron is non-trivial, sometimes we skip versions until there is a clear benefit that justifies the cost. 8 | 9 | ## Change Process 10 | 11 | Like most things, we use the standard [GitHub Flow][flow]: 12 | 13 | 1. Create a branch 14 | 1. Add commits 15 | 1. Create a Pull Request 16 | 1. Discuss and review your code 17 | 1. Merge 18 | 19 | Since most Electron updates require lots of testing and associated changes, these often require a lot of review, discussion and additional commits. (For example see [the PR to update to Electron v0.37][electron-pr].) We like doing all of this work in one PR because this strategy: 20 | 21 | 1. Allows us to continue focusing on moving Atom forward without getting bogged down by Electron changes 22 | 1. Allows us to focus the people who are interested in having the latest Electron in one place 23 | 1. Allows us to make sweeping changes when they are necessary without having to nickel-and-dime ourselves with one- or two-line PRs *ad infinitum* 24 | 1. Allows us to ensure that packages remain compatible with the older version of Electron even as they are updated 25 | 1. Allows us to easily abandon Electron changes when it makes sense (such as to skip Electron versions) 26 | 27 | ## Contributing 28 | 29 | If there is a version of Electron that you want Atom to be using that it isn't yet, you may [open a Pull Request][pr] and start the process. Please [do a search first][electron-pr-search] to ensure that there isn't one already open for that version or an earlier version. If there is a PR already open for an earlier version than the one you want, it is better to help the earlier version get delivered than to start a new PR. Additionally, if you open an Electron update PR please state specifically what benefit updating will provide to Atom users. Maybe there is a benefit that the Atom team has overlooked! 30 | 31 | ## FAQ 32 | 33 | **Q:** Should I open an Issue if Atom is not on the latest version of Electron? 34 | 35 | No. Updating to the latest version of Electron is an ongoing task that we will do as and when we can. 36 | 37 | **Q:** Why can't you stay closer to the latest version? 38 | 39 | Updating to new versions of Electron, even patch releases, is almost always non-trivial. Since Electron contains the base libraries that form the underpinnings of everything in Atom, even small changes in Electron can create significant problems. Updating to the latest version of Electron is something we undertake only when the benefits outweigh the cost. If there isn't a specific benefit to Atom's users, we won't upgrade to that version of Electron. 40 | 41 | **Q:** Where can I ask more questions? 42 | 43 | Please open a new topic on [Discuss, the official Atom and Electron message board][discuss]. 44 | 45 | [discuss]: https://discuss.atom.io 46 | [electron-pr]: https://github.com/atom/atom/pull/11474 47 | [electron-pr-search]: https://github.com/atom/atom/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+electron 48 | [flow]: https://guides.github.com/introduction/flow/index.html 49 | [pr]: https://help.github.com/articles/creating-a-pull-request/ 50 | -------------------------------------------------------------------------------- /unofficial-atom-distributions.md: -------------------------------------------------------------------------------- 1 | # Unofficial Atom Distributions 2 | 3 | **Question:** Some Linux enthusiasts are distributing unofficial customized versions of Atom with mismatched components that neither the Atom Core team nor GitHub have tested, certified or authorized. Do we support these unofficial customized versions of Atom? Can we support these unofficial versions of Atom? 4 | 5 | ## Why is Customizing Atom a Problem? 6 | 7 | Often these customized versions of Atom are modified versions of the Stable branch of Atom with mismatched versions of built-in components. These updated components are taken from the Beta or `master` branches and then injected into the Stable branch and a new Atom package is generated. 8 | 9 | The way Atom is designed and built by the Atom Core team, built-in components are tested and verified to work with specific versions of all the other built-in components. Importing mismatching versions of built-in components often lead to uncaught exceptions and crashes because of mismatched or even missing APIs. These exceptions and crashes can cause a lot of effort to track down and the solution is often to simply install the properly tested version. 10 | 11 | ## Support 12 | 13 | The Atom Core team and GitHub currently support three released versions of Atom (`master`, Beta and Stable) across three major platforms (Linux, macOS and Windows). This generates hundreds of new Issues a week, not to mention the over 4,000 open Issues that we already have. Since these unofficial customized versions of Atom have started turning up, we have noticed an uptick in new Issues being reported. 14 | 15 | ## Decision 16 | 17 | The bottom line is, we don't have the resources to support these unofficial versions of Atom. Atom has plenty of valid bugs and enhancements that we want to make progress on. Every one of these Issues that we have to investigate takes time away from making Atom better. 18 | 19 | Therefore, any Issue reported from an installation of Atom that is discovered to contain mismatched components will be closed without further investigation. 20 | 21 | ## FAQ 22 | 23 | **Q:** Does this mean that we can't experiment? I thought Atom was open source? 24 | 25 | Atom is open source. We want people to experiment with it. We want people to try new things. Go nuts! We just don't have the resources to support your experiments the way we support the versions of Atom we release. 26 | --------------------------------------------------------------------------------