From e2eae3ac893dc38bdfda27b2ffcbdb28472a56b2 Mon Sep 17 00:00:00 2001 From: Simon Lydell Date: Sat, 20 Jun 2015 21:31:14 +0200 Subject: [PATCH] Init documentation --- CONTRIBUTING-CODE.md | 189 -------- CONTRIBUTING.md | 4 +- documentation/CONTRIBUTING-CODE.md | 84 ++++ documentation/GNU Free Documentation License | 451 +++++++++++++++++++ documentation/README.md | 15 + documentation/tools.md | 203 +++++++++ 6 files changed, 756 insertions(+), 190 deletions(-) delete mode 100644 CONTRIBUTING-CODE.md create mode 100644 documentation/CONTRIBUTING-CODE.md create mode 100644 documentation/GNU Free Documentation License create mode 100644 documentation/README.md create mode 100644 documentation/tools.md diff --git a/CONTRIBUTING-CODE.md b/CONTRIBUTING-CODE.md deleted file mode 100644 index d8cc834..0000000 --- a/CONTRIBUTING-CODE.md +++ /dev/null @@ -1,189 +0,0 @@ -# Contributing code - -## Localizing - -Contribute your localization! Copy the `extension/locale/en-US` directory and go -wild! - - -## Developing - -### Versioning and branches - -Currently, no more updates are planned for 0.5.x = master branch. **Please only -contribute to the develop branch for now.** It contains quite a bit of backwards -incomptaible improvements, and will be released as 0.6.0 as soon as it is ready. -That will be the last “big” release. Then we’ll switch to a more rapid release -cycle, detailed below. - -#### Vision #### - -VimFx uses three numbers to describe its version: x.y.z, or major.minor.patch. -However, in reality it is more like 0.y.z. The first number (major) won’t -change until we feel that we don’t have any major changes coming. So until then -it is only worth describing the two other numbers. - -The middle number (minor) is incremented when a release contains new features, -major refactors or changes to defaults. The idea is that when a user installs a -new minor release, they should expect changes that they need to get familiar -with. - -The last number (patch) is incremented when a release contains only (simple) -bugfixes, new localizations and updates to localizations. If a user installs a -new patch release they shouldn’t have to get familiar with anything. Things -should be like they were before, just a little better. - -VimFx uses two branches: **master** and **develop**. master is the latest -stable version plus trivial bugfixes. develop is the next minor version. master -is merged into develop when needed, and develop is merged into master before it -is going to be released. - -In short, “backwards-incomptaible” changes and new features go into the develop -branch, while most other things go into the master branch. - -### Pull requests - -Create a new topic branch, based on either master or develop. **Note:** For now, -_always_ base it on **develop**. - - git checkout -b myTopicBranch master - # or - git checkout -b myTopicBranch develop - -Code! Try to follow the following simple rules: - -- Always use parenthesis when calling functions. -- Always use explicit `return`s, unless the function is a one-liner. -- Always use single quotes, unless you use interpolation. -- Prefer interpolation over concatenation, both in strings and in regexes. -- Always use the following forms (not any aliases): - - `true` and `false` - - `==` and `!=` - - `and` and `or` - - `not` -- Put spaces inside `[]` and `{}` when destructuring and interpolating, but not - in array and object literals. -- Comment when necessary. Comments should be full sentences. -- Try to keep lines at most 80 characters long. -- Indent using two spaces. - -Please lint your code. See below. - -Run the tests and make sure that all pass. See below. Add tests if possible. - -Break up your pull request in several commits if necessary. The first line of -commit messages should be a short summary. Add a blank line and then a nicely -formatted markdown description after it if needed. - -Finally send a pull request to same branch as you based your topic branch on -(master or develop). - -### Building VimFx - -1. Install [Node.js] or [io.js]. -2. Run `npm install` to download dependencies and development dependencies. -3. Run `npm install -g gulp` to be able to run [`gulp`][gulp] commands. - If you prefer not to install gulp globally, you can use `npm run gulp` - instead. For example, to create an .xpi: `npm run gulp -- xpi`. (Note that - you might need to update `npm` for this to run; try `npm update -g npm`.) -4. Create a new Firefox profile for development. -5. Install the [Extension Auto-Installer] add-on in your development profile. - -- `gulp build` creates the `build/` directory. It is basically a copy of the - `extension/` directory, with the .coffee files compiled to .js. -- `gulp xpi` zips up the `build/` directory into `build/VimFx.xpi`. -- `gulp push` (or just `gulp`) pushes `build/VimFx.xpi` to - `http://localhost:8888`, which causes the Extension Auto-Installer to - automatically install it. (No need to restart Firefox.) -- `gulp clean` removes the `build/` directory. -- `gulp lint` lints your code. -- `gulp faster` compiles `gulpfile.coffee` to `gulpfile.js`. If you run `gulp` a - lot and wish it ran faster, just tell it and it will! You’ll have to remember - to re-run it whenever gulpfile.coffee is updated, though. -- `gulp sync-locales` syncs all locales against the en-US locale. To sync against - for example the sv-SE locale instead, pass `--sv-SE` as an option. See also - the “Syncing locales” section below. -- `gulp help.html` dumps VimFx’s Keyboard Shortcuts dialog into help.html. You - can then open up help.html in Firefox and style it live using the Style - Editor! You can even press the “Save” button when done to save your changes! -- Use the `--test` or `-t` option to include the unit test files. The output of - the tests are `console.log`ed. See the browser console, or start Firefox from - the command line to see it. - -An easy workflow is code, `gulp`, test, repeat. (Use `gulp -t` to also run the -unit tests.) - -If you’re having problems, don’t forget to try `npm update`. Your problem might -be in a dependency and already have been fixed. - -[Node.js]: http://nodejs.org/ -[io.js]: https://iojs.org/ -[gulp]: https://github.com/gulpjs/gulp -[Extension Auto-Installer]: https://addons.mozilla.org/firefox/addon/autoinstaller - -### Syncing locales - -This is usually not done by translators, but by developers who change, add or -remove features that involves localized text. - -If you add, remove or reorder translations in a file, do so in _one_ of the -locales (one that is easy for you to test—but always write new translations in -English!). If you modified the en-US locale, run `gulp sync-locales` (or `gulp -sync-locales --en-US`—substitute “en-US” with a locale of choice if needed). -That rewrites all other locales so that: - -- Old translations are removed. -- New translations are added (in English). -- All translations appear in the same order. - -If you modify an existing translation in a file and want to update all other -locales to use the new wording: - -- If possible, edit all other locales by hand to save as much translated text as - possible. -- Otherwise: - 1. Before modifying existing translations, copy the file in question and add - the extension “.old” to the filename. For example, copy a - “vimfx.properties” file to “vimfx.properties.old”. - 2. Make your modifications (in for example “vimfx.properties”, leaving - “vimfx.properties.old” intact). - 3. Run `gulp sync-locales`. It does the same thing as before, except that if a - translation has changed compared to an “.old”-file, the newly changed - translation is used in all locales, replacing what was there before. - 4. Remove the “.old”-file. - -Note that `gulp sync-locales` requires every translation to be in a single line. -In other words, do not line-wrap translations. Also don’t bother adding comments -when translating locale files, since they’ll likely be removed by `gulp -sync-locales`. - - -### Making a release - -Before making a release, it might be wise to: - -- Run `npm update` and/or `npm outdated` to see if there are any updates to - dependencies. Investigate what’s new and test! -- Run `gulp sync-locales` to make sure that no translation has been left behind. -- Inspect the build/ directory to see that nothing strange has been included or - generated by `gulp build`. - -1. Add a list of changes since the last version at the top of CHANGELOG.md. -2. Update the version in package.json (see above about versioning), and, if - needed, the minimum Firefox version. -3. Run `gulp release`, which does the following for you: - - Adds a heading with the new version number and today’s date at the top of - CHANGELOG.md. - - Commits CHANGELOG.md and package.json. - - Tags the commit. -4. Run `gulp xpi` to rebuild with the new version number. -5. Push to github. Don’t forget to push the tag! -6. Make a “release” out of the new tag on github, and attach VimFx.xpi to it. -7. Publish on addons.mozilla.org. Add the release notes list as HTML. `gulp - changelog` prints the latest changelog entry as HTML. `gulp changelog -2` - prints the latest two (etc). The latter is useful if publishing a new version - before the last published version has been reviewed; then the new version - should contain both changelog entries. - -The idea is to use the contents of the README as the add-on descripton on -addons.mozilla.org. You can print it as HTML by runnning `gulp readme`. diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 31d345f..01c0fae 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -4,4 +4,6 @@ Provide an example **URL** where it happens. Also, **did it use to work before?** - Feature requests: Include a specific detailed **use case** example. -Contributing code? See [CONTRIBUTING-CODE.md](CONTRIBUTING-CODE.md). +Contributing code? See [documentation/CONTRIBUTING-CODE.md][code-contrib] + +[code-contrib]: documentation/CONTRIBUTING-CODE.md diff --git a/documentation/CONTRIBUTING-CODE.md b/documentation/CONTRIBUTING-CODE.md new file mode 100644 index 0000000..4ee4f96 --- /dev/null +++ b/documentation/CONTRIBUTING-CODE.md @@ -0,0 +1,84 @@ + + +# Contributing code + +## Localizations + +Contribute your localization! Copy the `extension/locale/en-US` directory and go +wild! + + +## Code + +Create a new topic branch, based on either master or develop. **Note:** For now, +_always_ base it on **develop**. + + git checkout -b my-topic-branch master + # or + git checkout -b my-topic-branch develop + +Code! Try to follow the following simple rules: + +- Always use parenthesis when calling functions. +- Always use explicit `return`s, unless the function is a one-liner. +- Always use single quotes, unless you use interpolation. +- Prefer interpolation over concatenation, both in strings and in regexes. +- Always use the following forms (not any aliases): + - `true` and `false` + - `==` and `!=` + - `and` and `or` + - `not` +- Put spaces inside `[]` and `{}` when destructuring and interpolating, but not + in array and object literals. +- Comment when necessary. Comments should be full sentences. +- Try to keep lines at most 80 characters long. +- Indent using two spaces. + +See [tools.md] for how to **build,** **lint,** and **run the tests.** + +Break up your pull request in several commits if necessary. The first line of +commit messages should be a short summary. Add a blank line and then a nicely +formatted markdown description after it if needed. + +Finally send a pull request to same branch as you based your topic branch on +(master or develop). + +[tools.md]: tools.md + + +## Versioning and branches + +Currently, no more updates are planned for 0.5.x = master branch. **Please only +contribute to the develop branch for now.** It contains quite a bit of backwards +incomptaible improvements, and will be released as 0.6.0 as soon as it is ready. +That will be the last “big” release. Then we’ll switch to a more rapid release +cycle, detailed below. + +### Vision + +VimFx uses three numbers to describe its version: x.y.z, or major.minor.patch. +However, in reality it is more like 0.y.z. The first number (major) won’t +change until we feel that we don’t have any major changes coming. So until then +it is only worth describing the two other numbers. + +The middle number (minor) is incremented when a release contains new features, +major refactors or changes to defaults. The idea is that when a user installs a +new minor release, they should expect changes that they need to get familiar +with. + +The last number (patch) is incremented when a release contains only (simple) +bugfixes, new localizations and updates to localizations. If a user installs a +new patch release they shouldn’t have to get familiar with anything. Things +should be like they were before, just a little better. + +VimFx uses two branches: **master** and **develop**. master is the latest +stable version plus trivial bugfixes. develop is the next minor version. master +is merged into develop when needed, and develop is merged into master before it +is going to be released. + +In short, “backwards-incomptaible” changes and new features go into the develop +branch, while most other things go into the master branch. diff --git a/documentation/GNU Free Documentation License b/documentation/GNU Free Documentation License new file mode 100644 index 0000000..2f7e03c --- /dev/null +++ b/documentation/GNU Free Documentation License @@ -0,0 +1,451 @@ + + GNU Free Documentation License + Version 1.3, 3 November 2008 + + + Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc. + + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + +0. PREAMBLE + +The purpose of this License is to make a manual, textbook, or other +functional and useful document "free" in the sense of freedom: to +assure everyone the effective freedom to copy and redistribute it, +with or without modifying it, either commercially or noncommercially. +Secondarily, this License preserves for the author and publisher a way +to get credit for their work, while not being considered responsible +for modifications made by others. + +This License is a kind of "copyleft", which means that derivative +works of the document must themselves be free in the same sense. It +complements the GNU General Public License, which is a copyleft +license designed for free software. + +We have designed this License in order to use it for manuals for free +software, because free software needs free documentation: a free +program should come with manuals providing the same freedoms that the +software does. But this License is not limited to software manuals; +it can be used for any textual work, regardless of subject matter or +whether it is published as a printed book. We recommend this License +principally for works whose purpose is instruction or reference. + + +1. APPLICABILITY AND DEFINITIONS + +This License applies to any manual or other work, in any medium, that +contains a notice placed by the copyright holder saying it can be +distributed under the terms of this License. Such a notice grants a +world-wide, royalty-free license, unlimited in duration, to use that +work under the conditions stated herein. The "Document", below, +refers to any such manual or work. Any member of the public is a +licensee, and is addressed as "you". You accept the license if you +copy, modify or distribute the work in a way requiring permission +under copyright law. + +A "Modified Version" of the Document means any work containing the +Document or a portion of it, either copied verbatim, or with +modifications and/or translated into another language. + +A "Secondary Section" is a named appendix or a front-matter section of +the Document that deals exclusively with the relationship of the +publishers or authors of the Document to the Document's overall +subject (or to related matters) and contains nothing that could fall +directly within that overall subject. (Thus, if the Document is in +part a textbook of mathematics, a Secondary Section may not explain +any mathematics.) The relationship could be a matter of historical +connection with the subject or with related matters, or of legal, +commercial, philosophical, ethical or political position regarding +them. + +The "Invariant Sections" are certain Secondary Sections whose titles +are designated, as being those of Invariant Sections, in the notice +that says that the Document is released under this License. If a +section does not fit the above definition of Secondary then it is not +allowed to be designated as Invariant. The Document may contain zero +Invariant Sections. If the Document does not identify any Invariant +Sections then there are none. + +The "Cover Texts" are certain short passages of text that are listed, +as Front-Cover Texts or Back-Cover Texts, in the notice that says that +the Document is released under this License. A Front-Cover Text may +be at most 5 words, and a Back-Cover Text may be at most 25 words. + +A "Transparent" copy of the Document means a machine-readable copy, +represented in a format whose specification is available to the +general public, that is suitable for revising the document +straightforwardly with generic text editors or (for images composed of +pixels) generic paint programs or (for drawings) some widely available +drawing editor, and that is suitable for input to text formatters or +for automatic translation to a variety of formats suitable for input +to text formatters. A copy made in an otherwise Transparent file +format whose markup, or absence of markup, has been arranged to thwart +or discourage subsequent modification by readers is not Transparent. +An image format is not Transparent if used for any substantial amount +of text. A copy that is not "Transparent" is called "Opaque". + +Examples of suitable formats for Transparent copies include plain +ASCII without markup, Texinfo input format, LaTeX input format, SGML +or XML using a publicly available DTD, and standard-conforming simple +HTML, PostScript or PDF designed for human modification. Examples of +transparent image formats include PNG, XCF and JPG. Opaque formats +include proprietary formats that can be read and edited only by +proprietary word processors, SGML or XML for which the DTD and/or +processing tools are not generally available, and the +machine-generated HTML, PostScript or PDF produced by some word +processors for output purposes only. + +The "Title Page" means, for a printed book, the title page itself, +plus such following pages as are needed to hold, legibly, the material +this License requires to appear in the title page. For works in +formats which do not have any title page as such, "Title Page" means +the text near the most prominent appearance of the work's title, +preceding the beginning of the body of the text. + +The "publisher" means any person or entity that distributes copies of +the Document to the public. + +A section "Entitled XYZ" means a named subunit of the Document whose +title either is precisely XYZ or contains XYZ in parentheses following +text that translates XYZ in another language. (Here XYZ stands for a +specific section name mentioned below, such as "Acknowledgements", +"Dedications", "Endorsements", or "History".) To "Preserve the Title" +of such a section when you modify the Document means that it remains a +section "Entitled XYZ" according to this definition. + +The Document may include Warranty Disclaimers next to the notice which +states that this License applies to the Document. These Warranty +Disclaimers are considered to be included by reference in this +License, but only as regards disclaiming warranties: any other +implication that these Warranty Disclaimers may have is void and has +no effect on the meaning of this License. + +2. VERBATIM COPYING + +You may copy and distribute the Document in any medium, either +commercially or noncommercially, provided that this License, the +copyright notices, and the license notice saying this License applies +to the Document are reproduced in all copies, and that you add no +other conditions whatsoever to those of this License. You may not use +technical measures to obstruct or control the reading or further +copying of the copies you make or distribute. However, you may accept +compensation in exchange for copies. If you distribute a large enough +number of copies you must also follow the conditions in section 3. + +You may also lend copies, under the same conditions stated above, and +you may publicly display copies. + + +3. COPYING IN QUANTITY + +If you publish printed copies (or copies in media that commonly have +printed covers) of the Document, numbering more than 100, and the +Document's license notice requires Cover Texts, you must enclose the +copies in covers that carry, clearly and legibly, all these Cover +Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on +the back cover. Both covers must also clearly and legibly identify +you as the publisher of these copies. The front cover must present +the full title with all words of the title equally prominent and +visible. You may add other material on the covers in addition. +Copying with changes limited to the covers, as long as they preserve +the title of the Document and satisfy these conditions, can be treated +as verbatim copying in other respects. + +If the required texts for either cover are too voluminous to fit +legibly, you should put the first ones listed (as many as fit +reasonably) on the actual cover, and continue the rest onto adjacent +pages. + +If you publish or distribute Opaque copies of the Document numbering +more than 100, you must either include a machine-readable Transparent +copy along with each Opaque copy, or state in or with each Opaque copy +a computer-network location from which the general network-using +public has access to download using public-standard network protocols +a complete Transparent copy of the Document, free of added material. +If you use the latter option, you must take reasonably prudent steps, +when you begin distribution of Opaque copies in quantity, to ensure +that this Transparent copy will remain thus accessible at the stated +location until at least one year after the last time you distribute an +Opaque copy (directly or through your agents or retailers) of that +edition to the public. + +It is requested, but not required, that you contact the authors of the +Document well before redistributing any large number of copies, to +give them a chance to provide you with an updated version of the +Document. + + +4. MODIFICATIONS + +You may copy and distribute a Modified Version of the Document under +the conditions of sections 2 and 3 above, provided that you release +the Modified Version under precisely this License, with the Modified +Version filling the role of the Document, thus licensing distribution +and modification of the Modified Version to whoever possesses a copy +of it. In addition, you must do these things in the Modified Version: + +A. Use in the Title Page (and on the covers, if any) a title distinct + from that of the Document, and from those of previous versions + (which should, if there were any, be listed in the History section + of the Document). You may use the same title as a previous version + if the original publisher of that version gives permission. +B. List on the Title Page, as authors, one or more persons or entities + responsible for authorship of the modifications in the Modified + Version, together with at least five of the principal authors of the + Document (all of its principal authors, if it has fewer than five), + unless they release you from this requirement. +C. State on the Title page the name of the publisher of the + Modified Version, as the publisher. +D. Preserve all the copyright notices of the Document. +E. Add an appropriate copyright notice for your modifications + adjacent to the other copyright notices. +F. Include, immediately after the copyright notices, a license notice + giving the public permission to use the Modified Version under the + terms of this License, in the form shown in the Addendum below. +G. Preserve in that license notice the full lists of Invariant Sections + and required Cover Texts given in the Document's license notice. +H. Include an unaltered copy of this License. +I. Preserve the section Entitled "History", Preserve its Title, and add + to it an item stating at least the title, year, new authors, and + publisher of the Modified Version as given on the Title Page. If + there is no section Entitled "History" in the Document, create one + stating the title, year, authors, and publisher of the Document as + given on its Title Page, then add an item describing the Modified + Version as stated in the previous sentence. +J. Preserve the network location, if any, given in the Document for + public access to a Transparent copy of the Document, and likewise + the network locations given in the Document for previous versions + it was based on. These may be placed in the "History" section. + You may omit a network location for a work that was published at + least four years before the Document itself, or if the original + publisher of the version it refers to gives permission. +K. For any section Entitled "Acknowledgements" or "Dedications", + Preserve the Title of the section, and preserve in the section all + the substance and tone of each of the contributor acknowledgements + and/or dedications given therein. +L. Preserve all the Invariant Sections of the Document, + unaltered in their text and in their titles. Section numbers + or the equivalent are not considered part of the section titles. +M. Delete any section Entitled "Endorsements". Such a section + may not be included in the Modified Version. +N. Do not retitle any existing section to be Entitled "Endorsements" + or to conflict in title with any Invariant Section. +O. Preserve any Warranty Disclaimers. + +If the Modified Version includes new front-matter sections or +appendices that qualify as Secondary Sections and contain no material +copied from the Document, you may at your option designate some or all +of these sections as invariant. To do this, add their titles to the +list of Invariant Sections in the Modified Version's license notice. +These titles must be distinct from any other section titles. + +You may add a section Entitled "Endorsements", provided it contains +nothing but endorsements of your Modified Version by various +parties--for example, statements of peer review or that the text has +been approved by an organization as the authoritative definition of a +standard. + +You may add a passage of up to five words as a Front-Cover Text, and a +passage of up to 25 words as a Back-Cover Text, to the end of the list +of Cover Texts in the Modified Version. Only one passage of +Front-Cover Text and one of Back-Cover Text may be added by (or +through arrangements made by) any one entity. If the Document already +includes a cover text for the same cover, previously added by you or +by arrangement made by the same entity you are acting on behalf of, +you may not add another; but you may replace the old one, on explicit +permission from the previous publisher that added the old one. + +The author(s) and publisher(s) of the Document do not by this License +give permission to use their names for publicity for or to assert or +imply endorsement of any Modified Version. + + +5. COMBINING DOCUMENTS + +You may combine the Document with other documents released under this +License, under the terms defined in section 4 above for modified +versions, provided that you include in the combination all of the +Invariant Sections of all of the original documents, unmodified, and +list them all as Invariant Sections of your combined work in its +license notice, and that you preserve all their Warranty Disclaimers. + +The combined work need only contain one copy of this License, and +multiple identical Invariant Sections may be replaced with a single +copy. If there are multiple Invariant Sections with the same name but +different contents, make the title of each such section unique by +adding at the end of it, in parentheses, the name of the original +author or publisher of that section if known, or else a unique number. +Make the same adjustment to the section titles in the list of +Invariant Sections in the license notice of the combined work. + +In the combination, you must combine any sections Entitled "History" +in the various original documents, forming one section Entitled +"History"; likewise combine any sections Entitled "Acknowledgements", +and any sections Entitled "Dedications". You must delete all sections +Entitled "Endorsements". + + +6. COLLECTIONS OF DOCUMENTS + +You may make a collection consisting of the Document and other +documents released under this License, and replace the individual +copies of this License in the various documents with a single copy +that is included in the collection, provided that you follow the rules +of this License for verbatim copying of each of the documents in all +other respects. + +You may extract a single document from such a collection, and +distribute it individually under this License, provided you insert a +copy of this License into the extracted document, and follow this +License in all other respects regarding verbatim copying of that +document. + + +7. AGGREGATION WITH INDEPENDENT WORKS + +A compilation of the Document or its derivatives with other separate +and independent documents or works, in or on a volume of a storage or +distribution medium, is called an "aggregate" if the copyright +resulting from the compilation is not used to limit the legal rights +of the compilation's users beyond what the individual works permit. +When the Document is included in an aggregate, this License does not +apply to the other works in the aggregate which are not themselves +derivative works of the Document. + +If the Cover Text requirement of section 3 is applicable to these +copies of the Document, then if the Document is less than one half of +the entire aggregate, the Document's Cover Texts may be placed on +covers that bracket the Document within the aggregate, or the +electronic equivalent of covers if the Document is in electronic form. +Otherwise they must appear on printed covers that bracket the whole +aggregate. + + +8. TRANSLATION + +Translation is considered a kind of modification, so you may +distribute translations of the Document under the terms of section 4. +Replacing Invariant Sections with translations requires special +permission from their copyright holders, but you may include +translations of some or all Invariant Sections in addition to the +original versions of these Invariant Sections. You may include a +translation of this License, and all the license notices in the +Document, and any Warranty Disclaimers, provided that you also include +the original English version of this License and the original versions +of those notices and disclaimers. In case of a disagreement between +the translation and the original version of this License or a notice +or disclaimer, the original version will prevail. + +If a section in the Document is Entitled "Acknowledgements", +"Dedications", or "History", the requirement (section 4) to Preserve +its Title (section 1) will typically require changing the actual +title. + + +9. TERMINATION + +You may not copy, modify, sublicense, or distribute the Document +except as expressly provided under this License. Any attempt +otherwise to copy, modify, sublicense, or distribute it is void, and +will automatically terminate your rights under this License. + +However, if you cease all violation of this License, then your license +from a particular copyright holder is reinstated (a) provisionally, +unless and until the copyright holder explicitly and finally +terminates your license, and (b) permanently, if the copyright holder +fails to notify you of the violation by some reasonable means prior to +60 days after the cessation. + +Moreover, your license from a particular copyright holder is +reinstated permanently if the copyright holder notifies you of the +violation by some reasonable means, this is the first time you have +received notice of violation of this License (for any work) from that +copyright holder, and you cure the violation prior to 30 days after +your receipt of the notice. + +Termination of your rights under this section does not terminate the +licenses of parties who have received copies or rights from you under +this License. If your rights have been terminated and not permanently +reinstated, receipt of a copy of some or all of the same material does +not give you any rights to use it. + + +10. FUTURE REVISIONS OF THIS LICENSE + +The Free Software Foundation may publish new, revised versions of the +GNU Free Documentation License from time to time. Such new versions +will be similar in spirit to the present version, but may differ in +detail to address new problems or concerns. See +http://www.gnu.org/copyleft/. + +Each version of the License is given a distinguishing version number. +If the Document specifies that a particular numbered version of this +License "or any later version" applies to it, you have the option of +following the terms and conditions either of that specified version or +of any later version that has been published (not as a draft) by the +Free Software Foundation. If the Document does not specify a version +number of this License, you may choose any version ever published (not +as a draft) by the Free Software Foundation. If the Document +specifies that a proxy can decide which future versions of this +License can be used, that proxy's public statement of acceptance of a +version permanently authorizes you to choose that version for the +Document. + +11. RELICENSING + +"Massive Multiauthor Collaboration Site" (or "MMC Site") means any +World Wide Web server that publishes copyrightable works and also +provides prominent facilities for anybody to edit those works. A +public wiki that anybody can edit is an example of such a server. A +"Massive Multiauthor Collaboration" (or "MMC") contained in the site +means any set of copyrightable works thus published on the MMC site. + +"CC-BY-SA" means the Creative Commons Attribution-Share Alike 3.0 +license published by Creative Commons Corporation, a not-for-profit +corporation with a principal place of business in San Francisco, +California, as well as future copyleft versions of that license +published by that same organization. + +"Incorporate" means to publish or republish a Document, in whole or in +part, as part of another Document. + +An MMC is "eligible for relicensing" if it is licensed under this +License, and if all works that were first published under this License +somewhere other than this MMC, and subsequently incorporated in whole or +in part into the MMC, (1) had no cover texts or invariant sections, and +(2) were thus incorporated prior to November 1, 2008. + +The operator of an MMC Site may republish an MMC contained in the site +under CC-BY-SA on the same site at any time before August 1, 2009, +provided the MMC is eligible for relicensing. + + +ADDENDUM: How to use this License for your documents + +To use this License in a document you have written, include a copy of +the License in the document and put the following copyright and +license notices just after the title page: + + Copyright (c) YEAR YOUR NAME. + Permission is granted to copy, distribute and/or modify this document + under the terms of the GNU Free Documentation License, Version 1.3 + or any later version published by the Free Software Foundation; + with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. + A copy of the license is included in the section entitled "GNU + Free Documentation License". + +If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, +replace the "with...Texts." line with this: + + with the Invariant Sections being LIST THEIR TITLES, with the + Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST. + +If you have Invariant Sections without Cover Texts, or some other +combination of the three, merge those two alternatives to suit the +situation. + +If your document contains nontrivial examples of program code, we +recommend releasing these examples in parallel under your choice of +free software license, such as the GNU General Public License, +to permit their use in free software. diff --git a/documentation/README.md b/documentation/README.md new file mode 100644 index 0000000..b0b2a8e --- /dev/null +++ b/documentation/README.md @@ -0,0 +1,15 @@ +# VimFx documentation + +Copyright Simon Lydell 2015. + +Permission is granted to copy, distribute and/or modify this document +under the terms of the GNU Free Documentation License, Version 1.3 +or any later version published by the Free Software Foundation; +with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. +A copy of the license is included in the file ["GNU Free Documentation +License"][license]. + +This documentation is split into several section, each in its own file. You can +read them in any order. + +[license]: GNU%20Free%20Documentation%20License diff --git a/documentation/tools.md b/documentation/tools.md new file mode 100644 index 0000000..34905b9 --- /dev/null +++ b/documentation/tools.md @@ -0,0 +1,203 @@ + + +# Tools + +This section describes how to install and use the tools needed to: + +- Build VimFx from source +- Lint code +- Sync locales +- Prepare releases + + +## Installation + +1. Install [Node.js] or [io.js]. + +2. Run `npm install` to download dependencies and development dependencies. + +3. Optional: Run `npm install -g gulp` to be able to run [`gulp`][gulp] tasks. + + If you prefer not to install gulp globally, you can use `npm run gulp` + instead. For example, to create an `.xpi`: `npm run gulp -- xpi`. (Note that + you might need to update `npm` for this to run; try `npm update -g npm`.) + +[Node.js]: http://nodejs.org/ +[io.js]: https://iojs.org/ +[gulp]: https://github.com/gulpjs/gulp + +## Getting started + +### How to build and install the latest version from source + +1. Follow the installation instructions above. + +2. Run `npm run gulp -- xpi`. + +3. Install `build/VimFx.xpi` in Firefox by doing one of the following: + + - Dragging and dropping it. + - Pressing ctrl+o and choosing it. + - Using “Install from file…” in the top-right menu in the Add-ons Manager. + +### Development + +1. Create a new [Firefox profile] for development. + +2. Install the [Extension Auto-Installer] add-on in your development profile. + +An easy workflow is code, `gulp`, test, repeat. (Use `gulp -t` to also run the +unit tests.) + +If you’re having problems, don’t forget to try `npm update`. Your problem might +be in a dependency and already have been fixed. + +[Firefox Profile]: https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles +[Extension Auto-Installer]: https://addons.mozilla.org/firefox/addon/autoinstaller + + +## Gulp tasks + +[gulp] is the task runner used to automate most of the common VimFx tasks. + +The tasks are defined in [gulpfile.coffee]. They are summarized in the follwing +sub-sections. + +(There are a few more tasks defined in [gulpfile.coffee], but they are only used +internally by other tasks.) + +[gulpfile.coffee]: ../gulpfile.coffee + +### Building + +- `gulp build` creates the `build/` directory. It is basically a copy of the + `extension/` directory, with some of the files being compiled. For example, + the `.coffee` files compiled to `.js`. + +- `gulp xpi` runs `gulp build` and then zips the `build/` directory into + `build/VimFx.xpi`. + +- `gulp push` (or just `gulp`) runs `gulp xpi` and then pushes `build/VimFx.xpi` + to `http://localhost:8888`, which causes the [Extension Auto-Installer] to + automatically install it. (No need to restart Firefox.) + +- Use the `--test` or `-t` option to include the unit test files. The output of + the tests are `console.log`ed. See the browser console, or start Firefox from + the command line to see it. + +- `gulp clean` removes the `build/` directory. + +### Management + +- `gulp lint` lints all `.coffee` files. + +- `gulp sync-locales` syncs locales. See the [“Syncing locales”][sync-locales] + section below for more information. + +[sync-locales]: #syncing-locales + +### Helpers + +- `gulp faster` compiles `gulpfile.coffee` to `gulpfile.js`. If you run `gulp` a + lot and wish it ran faster, just tell it and it will! You’ll have to remember + to re-run it whenever gulpfile.coffee is updated, though. + +- `gulp help.html` dumps VimFx’s Keyboard Shortcuts dialog into `help.html`. You + can then open up `help.html` in Firefox and style it live using the Style + Editor! You can even press the “Save” button when done to save your changes! + +### Release + +See the [“Making a release”][release] section below for more information. + +- `gulp release` tags things with a new version number. + +- `gulp changelog` prints changelog entries from `CHANGELOG.md` as HTML to + stdout. + +- `gulp readme` prints `README.md` as HTML to stdout. + +[release]: #making-a-release + + +## Syncing locales + +This is usually not done by translators, but by developers who change, add or +remove features that involves localized text. + +If you add, remove or reorder translations in a file, do so in _one_ of the +locales (one that is easy for you to test—but always write new translations in +English!). If you modified the en-US locale, run `gulp sync-locales --en-US` (or +just `gulp sync-locales`). Substitute “en-US” with a locale of choice if needed. +That rewrites all other locales so that: + +- Old translations are removed. +- New translations are added (in English). +- All translations appear in the same order. + +If you modify an existing translation in a file and want to update all other +locales to use the new wording: + +- If possible, edit all other locales by hand to save as much translated text as + possible. + +- Otherwise: + + 1. Before modifying existing translations, copy the file in question and add + the extension `.old` to the filename. For example, copy a + `vimfx.properties` file to `vimfx.properties.old`. + 2. Make your modifications (in for example `vimfx.properties`, leaving + `vimfx.properties.old` intact). + 3. Run `gulp sync-locales`. It does the same thing as before, except that if a + translation has changed compared to an `.old`-file, the newly changed + translation is used in all locales, replacing what was there before. + 4. Remove the `.old`-file. + +Note that `gulp sync-locales` requires every translation to be in a single line. +In other words, do not line-wrap translations. Also don’t bother adding comments +when translating locale files, since they’ll likely be removed by `gulp +sync-locales`. + + +## Making a release + +Before making a release, it might be wise to: + +- Run `npm update` and/or `npm outdated` to see if there are any updates to + dependencies. Investigate what’s new and test! +- Run `gulp sync-locales` to make sure that no translation has been left behind. +- Inspect the `build/` directory to see that nothing strange has been included + or generated by `gulp build`. + +Steps: + +1. Add a list of changes since the last version at the top of `CHANGELOG.md`. + +2. Update the version in `package.json` (see `CONTRIBUTING-CODE.md` about + versioning), and, if needed, the minimum Firefox version. + +3. Run `gulp release`, which does the following for you: + + - Adds a heading with the new version number and today’s date at the top of + CHANGELOG.md. + - Commits CHANGELOG.md and package.json. + - Tags the commit. + +4. Run `gulp xpi` to rebuild with the new version number. + +5. Push to github. Don’t forget to push the tag! + +6. Make a “release” out of the new tag on github, and attach VimFx.xpi to it. + +7. Publish on addons.mozilla.org. Add the release notes list as HTML. `gulp + changelog` prints the latest changelog entry as HTML. `gulp changelog -2` + prints the latest two (etc). The latter is useful if publishing a new version + before the last published version had been reviewed; then the new version + should contain both changelog entries. + +The idea is to use the contents of `README.md` as the add-on descripton on +addons.mozilla.org. You can print it as HTML by runnning `gulp readme`. -- 2.39.3