c7acb932ec7c88ddfc2eb02b2c184525247354f5
[yaffs-website] / web / themes / contrib / bootstrap / docs / Maintainers.md
1 <!-- @file Maintaining the Drupal Bootstrap project. -->
2 <!-- @defgroup -->
3 # Maintainers
4
5 Generally speaking, these topics will not be very helpful to you unless you are
6 a maintainer for this project. If you're simply curious about the process or
7 even want to help improve this aspect of the project, all suggestions will be
8 appreciated!
9
10 ## Prerequisites
11 For development, this project relies heavily on NodeJS/Grunt to automate some
12 very time consuming tasks and to ensure consistent output. If you do not have
13 these CLI tools, please install them now:
14
15 * https://nodejs.org
16 * http://gruntjs.com
17
18 ## Installation
19 This project's installation may initially take a while to complete. Please read
20 through the entire topic before continuing and be aware of what to expect.
21 Suffice it to say: you will not have to manually update this project again.
22
23 After you have installed the prerequisite CLI tools, run `npm install` in this
24 directory. This will install the necessary NodeJS modules inside the
25 `node_modules` directory.
26
27 After NodeJS has finished installing its own modules, it will automatically
28 invoke `grunt install` for you. This is a grunt task that is specifically
29 designed to keep the project in sync amongst maintainers.
30
31 ## Drush
32 There are several commands available to run, please execute `drush` to view the
33 full list. This topic only covers the commands this project created.
34
35 ### `drush bootstrap-generate-docs` or `drush bs-docs`
36 Generates markdown documentation for the Drupal based code. Possible arguments:
37 - **type:** The specific type of documentation to generate, defaults to `all`.
38   Possible values: `all|settings`
39
40 ## Grunt
41 There are several tasks available to run, please execute `grunt --help` to view
42 the full list of tasks currently available. This topic only covers the most
43 important or commonly used tasks.
44
45 ### `grunt install`
46 This task is automatically invoked as a `postinstall` event of `npm install`.
47 There should be no need to manually invoke this task. However, if you feel the
48 need to manual invoke this task, you may do so without fear of producing any
49 unintended side-effects. This is simply an alias for sub-tasks defined below.
50
51 ### `grunt githooks`
52 This is a sub-task of `grunt install`. It will automatically install the
53 necessary git hooks for this project. These git hooks allow the project to keep
54 track of changes to files in order to automate and ensure certain files are
55 committed (e.g. compiled CSS files). Do not worry, if you already have existing
56 git hook files in place, this will work around them.
57
58 Any time there is a change to `package.json`, `Gruntfile.js`, `.githooks.js.hbs`
59 or any of the files in the `grunt` subdirectory, the `npm install` task will
60 automatically be executed by the git hook itself. This allows the workflow to
61 be altered by one maintainer and those changes propagated to the others the
62 next time they pull down the repository.
63
64 ### `grunt sync`
65 This is a sub-task used by `grunt install`. It will automatically
66 download and install the various 3.x.x versions of the Bootstrap and Bootswatch
67 libraries for local development purposes in the `./lib` directory. This process
68 utilizes Bower and can initially take a while for it to fully complete.
69
70 Once you have the various versions of libraries have been installed, this task
71 becomes much faster. This task utilizes the jsDelivr API to determine which
72 versions to install. To avoid abusing API calls, this list is cached for one
73 week as the `.libraries` file in the root of this project. In the event that a
74 new list needs to be generated and the week cache expiration has not lifted,
75 you can either simply remove the file manually or run `grunt sync --force` to
76 force an API call and generate a new list.
77
78 ### `grunt clean-vendor-dirs`
79 This is a sub-task used by `grunt install`. Drupal currently does not exclude
80 vendor directories when scanning directories of modules/themes to look for
81 .info files. Some NodeJS modules actually are installed with files that have
82 this same extension, yet cannot be parsed by Drupal. Due to the nature of how
83 Drupal currently parses these files, it can cause a PCRE recursion in PHP. This
84 ultimately leads to a segmentation fault and thus rendering the site inoperable.
85 For more details, see: https://www.drupal.org/node/2329453
86
87 ### `grunt compile`
88 This task ensures that all the necessary variations of versions and themes of
89 Bootstrap and Bootswatch are compile from
90 `starterkits/less/less/overrides.less`. Typically, this task generates hundreds
91 of files and can take upwards of \~10 seconds to fully complete.
92
93 Optionally, if the `--dev` parameter is specified, this task will only compile
94 the starterkit's `overrides.less` file for the latest version of Bootstrap:
95
96 * `./css/<%= latestVersion/overrides.css`
97 * `./css/<%= latestVersion/overrides.min.css`
98
99 ### `grunt watch`
100 This task is responsible for watching various source files and executing the
101 appropriate tasks these source files are normally consumed by. With the caveat
102 of long compilation times mentioned in the previous section, it is highly
103 recommended running this task as such: `grunt watch --dev`. Keep in mind that
104 this limits the rapid development of the `overrides.less` file to the default
105 Bootstrap theme. If you have switched themes, you must manually compile all
106 the version and theme override files.
107
108 ## Releases
109 This project attempts to provide more structured release notes. This allows the
110 project to communicate more effectively to the users what exactly has changed
111 and where to go for additional information. This documentation is intended for
112 the project maintainers to help provide consistent results between releases.
113
114 ### Release notes template
115 The following is just a template to show a typical structured format used as
116 release notes for this project:
117
118 ```html
119 <h3 id="change-records">Change Records</h3>
120 <!-- Change records table HTML -->
121
122 Optionally, you can insert any additional verbiage here.
123 However, if it is long, it should really be a change record.
124
125 <p>&nbsp;</p>
126 <h3 id="notes">Notes</h3>
127
128 <p>&nbsp;</p>
129 <p>Changes since <!-- previous release --> (<!-- commit count -->):</p>
130
131 <h3 id="features">New Features</h3>
132 <ul>
133   <li><!-- Issue/Commit Message --></li>
134 </ul>
135
136 <h3 id="bugs">Bug Fixes</h3>
137 <ul>
138   <li><!-- Issue/Commit Message --></li>
139 </ul>
140 ```
141
142 ### Create a Release Node
143
144 {.alert.alert-info} **NOTE:** This project currently relies on the
145 [Drush Git Release Notes](https://www.drupal.org/project/grn) tool to
146 automatically generate the the bulk of the release notes. This does, however,
147 requires maintainers to do the following extra steps. This entire process will
148 eventually be converted into a fully automated grunt task. Until then, please
149 download and install this tool and follow the remaining steps.
150
151 1. Create a [tag in git](https://www.drupal.org/node/1066342) that follows the
152    previous version and push it to the repository.
153 2. Create a [project release node](https://www.drupal.org/node/1068944) for this
154    newly created tag.
155 3. _(Skip this step if this is a new "alpha/beta" release)_ In a separate tab,
156    go to this project's [releases](https://www.drupal.org/node/259843/release)
157    page. Open and edit the previous release node. It should have followed the
158    release note template. If it has, copy and paste its contents into the new
159    release node body.
160 4. In a separate tab, go to the [change records](https://www.drupal.org/list-changes/bootstrap)
161    for this project and filter by the new official release version
162    ("alpha/beta/RC" releases should always use the next "official" version for
163    their change records). If there are no change records, then remove this
164    section. Otherwise, copy and paste the entire table into the template
165    (replacing any existing one, if necessary).
166 5. Generate a list of issues/commits by executing the following from the root
167    of the project:
168
169    `drush release-notes <old> <new> --commit-count`
170    (e.g. `drush release-notes 7.x-3.0 7.x-3.1 --commit-count`)
171
172    If this is a follow-up "alpha/beta/RC" release, always use the last
173    "alpha/beta/RC" release version instead. This will allow for a quicker
174    parsing of the list to merge into the previously copied release notes:
175
176    `drush release-notes <old> <new> --commit-count`
177    (e.g. `drush release-notes 7.x-3.1-beta2 7.x-3.1-beta3 --commit-count`)
178
179 6. Copy the entire generated output into the template, just under where the
180    "Change Records" section would be, replacing only the commit count (do not
181    replace the "since last {offical} version").
182 7. Go though each item (`<li>`) that contains an issue link, ignoring duplicates
183    and standalone verbiage (direct commits). Move (cut and paste) these items
184    into the appropriate "New Features" or "Bug Fixes" sections.
185 8. Once complete the generated list should be empty (e.g. `<ul></ul>`), remove
186    it.
187 9. Save the release node.