OLD | NEW |
(Empty) | |
| 1 # GYP (Generate Your Projects) Language Specification |
| 2 |
| 3 Status: Draft (as of 2009-01-30) |
| 4 |
| 5 Mark Mentovai <mark@chromium.org> _et al._ |
| 6 |
| 7 Modified: 2009-02-10 |
| 8 |
| 9 [TOC] |
| 10 |
| 11 ## Objective |
| 12 |
| 13 Create a tool for the Chromium project that generates native Visual Studio, |
| 14 Xcode and SCons and/or make build files from a platform-independent input |
| 15 format. Make the input format as reasonably general as possible without |
| 16 spending extra time trying to "get everything right," except where not doing so |
| 17 would likely lead Chromium to an eventual dead end. When in doubt, do what |
| 18 Chromium needs and don't worry about generalizing the solution. |
| 19 |
| 20 ## Background |
| 21 |
| 22 Numerous other projects, both inside and outside Google, have tried to |
| 23 create a simple, universal cross-platform build representation that |
| 24 still allows sufficient per-platform flexibility to accommodate |
| 25 irreconcilable differences. The fact that no obvious working candidate |
| 26 exists that meets Chromium's requirements indicates this is probably a |
| 27 tougher problem than it appears at first glance. We aim to succeed by |
| 28 creating a tool that is highly specific to Chromium's specific use case, |
| 29 not to the general case of design a completely platform-independent tool |
| 30 for expressing any possible build. |
| 31 |
| 32 The Mac has the most sophisticated model for application development |
| 33 through an IDE. Consequently, we will use the Xcode model as the |
| 34 starting point (the input file format must handle Chromium's use of |
| 35 Xcode seamlessly) and adapt the design as necessary for the other |
| 36 platforms. |
| 37 |
| 38 ## Overview |
| 39 |
| 40 The overall design has the following characteristics: |
| 41 |
| 42 * Input configurations are specified in files with the suffix `.gyp`. |
| 43 * Each `.gyp` file specifies how to build the targets for the |
| 44 "component" defined by that file. |
| 45 * Each `.gyp` file generates one or more output files appropriate to |
| 46 the platform: |
| 47 * On Mac, a `.gyp` file generates one Xcode .xcodeproj bundle with |
| 48 information about how its targets are built. |
| 49 * On Windows, a `.gyp` file generates one Visual Studio .sln file, |
| 50 and one Visual Studio .vcproj file per target. |
| 51 * On Linux, a `.gyp` file generates one SCons file and/or one |
| 52 Makefile per target |
| 53 * The `.gyp` file syntax is a Python data structure. |
| 54 * Use of arbitrary Python in `.gyp` files is forbidden. |
| 55 * Use of eval() with restricted globals and locals on `.gyp` file |
| 56 contents restricts the input to an evaluated expression, not |
| 57 arbitrary Python statements. |
| 58 * All input is expected to comply with JSON, with two exceptions: |
| 59 the # character (not inside strings) begins a comment that lasts |
| 60 until the end of the line, and trailing commas are permitted at |
| 61 the end of list and dict contents. |
| 62 * Input data is a dictionary of keywords and values. |
| 63 * "Invalid" keywords on any given data structure are not illegal, |
| 64 they're just ignored. |
| 65 * TODO: providing warnings on use of illegal keywords would help |
| 66 users catch typos. Figure out something nice to do with this. |
| 67 |
| 68 ## Detailed Design |
| 69 |
| 70 Some up-front design principles/thoughts/TODOs: |
| 71 |
| 72 * Re-use keywords consistently. |
| 73 * Keywords that allow configuration of a platform-specific concept get |
| 74 prefixed appropriately: |
| 75 * Examples: `msvs_disabled_warnings`, `xcode_framework_dirs` |
| 76 * The input syntax is declarative and data-driven. |
| 77 * This gets enforced by using Python `eval()` (which only evaluates |
| 78 an expression) instead of `exec` (which executes arbitrary python) |
| 79 * Semantic meanings of specific keyword values get deferred until all |
| 80 are read and the configuration is being evaluated to spit out the |
| 81 appropriate file(s) |
| 82 * Source file lists: |
| 83 * Are flat lists. Any imposed ordering within the `.gyp` file (e.g. |
| 84 alphabetically) is purely by convention and for developer |
| 85 convenience. When source files are linked or archived together, |
| 86 it is expected that this will occur in the order that files are |
| 87 listed in the `.gyp` file. |
| 88 * Source file lists contain no mechanism for by-hand folder |
| 89 configuration (`Filter` tags in Visual Studio, `Groups` in Xcode) |
| 90 * A folder hierarchy is created automatically that mirrors the file |
| 91 system |
| 92 |
| 93 ### Example |
| 94 |
| 95 ``` |
| 96 { |
| 97 'target_defaults': { |
| 98 'defines': [ |
| 99 'U_STATIC_IMPLEMENTATION', |
| 100 ['LOGFILE', 'foo.log',], |
| 101 ], |
| 102 'include_dirs': [ |
| 103 '..', |
| 104 ], |
| 105 }, |
| 106 'targets': [ |
| 107 { |
| 108 'target_name': 'foo', |
| 109 'type': 'static_library', |
| 110 'sources': [ |
| 111 'foo/src/foo.cc', |
| 112 'foo/src/foo_main.cc', |
| 113 ], |
| 114 'include_dirs': [ |
| 115 'foo', |
| 116 'foo/include', |
| 117 ], |
| 118 'conditions': [ |
| 119 [ 'OS==mac', { 'sources': [ 'platform_test_mac.mm' ] } ] |
| 120 ], |
| 121 'direct_dependent_settings': { |
| 122 'defines': [ |
| 123 'UNIT_TEST', |
| 124 ], |
| 125 'include_dirs': [ |
| 126 'foo', |
| 127 'foo/include', |
| 128 ], |
| 129 }, |
| 130 }, |
| 131 ], |
| 132 } |
| 133 ``` |
| 134 |
| 135 ### Structural Elements |
| 136 |
| 137 ### Top-level Dictionary |
| 138 |
| 139 This is the single dictionary in the `.gyp` file that defines the |
| 140 targets and how they're to be built. |
| 141 |
| 142 The following keywords are meaningful within the top-level dictionary |
| 143 definition: |
| 144 |
| 145 |:------------- |:------------------| |
| 146 | `conditions` | A conditional section that may contain other items that ca
n be present in a top-level dictionary, on a conditional basis. See the "Condit
ionals" section below. | |
| 147 | `includes` | A list of `.gypi` files to be included in the top-level di
ctionary. | |
| 148 | `target_defaults` | A dictionary of default settings to be inherited by all ta
rgets in the top-level dictionary. See the "Settings keywords" section below. | |
| 149 | `targets` | A list of target specifications. See the "targets" below.
| |
| 150 | `variables` | A dictionary containing variable definitions. Each key in
this dictionary is the name of a variable, and each value must be a string valu
e that the variable is to be set to. | |
| 151 |
| 152 ### targets |
| 153 |
| 154 A list of dictionaries defining targets to be built by the files |
| 155 generated from this `.gyp` file. |
| 156 |
| 157 Targets may contain `includes`, `conditions`, and `variables` sections |
| 158 as permitted in the root dictionary. The following additional keywords |
| 159 have structural meaning for target definitions: |
| 160 |
| 161 |:---------- |:------------------------------------------| |
| 162 | `actions` | A list of special custom actions to perform on
a specific input file, or files, to produce output files. See the "Actions" sec
tion below. | |
| 163 | `all_dependent_settings` | A dictionary of settings to be applied to all d
ependents of the target, transitively. This includes direct dependents and the
entire set of their dependents, and so on. This section may contain anything fo
und within a `target` dictionary, except `configurations`, `target_name`, and `t
ype` sections. Compare `direct_dependent_settings` and `link_settings`. | |
| 164 | `configurations` | A list of dictionaries defining build configura
tions for the target. See the "Configurations" section below. | |
| 165 | `copies` | A list of copy actions to perform. See the "Cop
ies" section below. | |
| 166 | `defines` | A list of preprocesor definitions to be passed
on the command line to the C/C++ compiler (via `-D` or `/D` options). | |
| 167 | `dependencies` | A list of targets on which this target depends.
Targets in other `.gyp` files are specified as `../path/to/other.gyp:target_we
_want`. | |
| 168 | `direct_dependent_settings` | A dictionary of settings to be applied to other
targets that depend on this target. These settings will only be applied to dir
ect dependents. This section may contain anything found within a `target` dicti
onary, except `configurations`, `target_name`, and `type` sections. Compare wit
h `all_dependent_settings` and `link_settings`. | |
| 169 | `include_dirs` | A list of include directories to be passed on t
he command line to the C/C++ compiler (via `-I` or `/I` options). | |
| 170 | `libraries` | A list of list of libraries (and/or frameworks)
on which this target depends. | |
| 171 | `link_settings` | A dictionary of settings to be applied to targe
ts in which this target's contents are linked. `executable` and `shared_library
` targets are linkable, so if they depend on a non-linkable target such as a `st
atic_library`, they will adopt its `link_settings`. This section can contain an
ything found within a `target` dictionary, except `configurations`, `target_name
`, and `type` sections. Compare `all_dependent_settings` and `direct_dependent_
settings`. | |
| 172 | `rules` | A special custom action to perform on a list of
input files, to produce output files. See the "Rules" section below. | |
| 173 | `sources` | A list of source files that are used to build t
his target or which should otherwise show up in the IDE for this target. In pra
ctice, we expect this list to be a union of all files necessary to build the tar
get on all platforms, as well as other related files that aren't actually used f
or building, like README files. | |
| 174 | `target_conditions` | Like `conditions`, but evaluation is delayed un
til the settings have been merged into an actual target. `target_conditions` ma
y be used to place conditionals into a `target_defaults` section but have them s
till depend on specific target settings. | |
| 175 | `target_name` | The name of a target being defined. | |
| 176 | `type` | The type of target being defined. This field cu
rrently supports `executable`, `static_library`, `shared_library`, and `none`.
The `none` target type is useful when producing output which is not linked. For
example, converting raw translation files into resources or documentation into p
latform specific help files. | |
| 177 | `msvs_props` | A list of Visual Studio property sheets (`.vspr
ops` files) to be used to build the target. | |
| 178 | `xcode_config_file` | An Xcode configuration (`.xcconfig` file) to be
used to build the target. | |
| 179 | `xcode_framework_dirs` | A list of framework directories be used to buil
d the target. | |
| 180 |
| 181 You can affect the way that lists/dictionaries are merged together (for |
| 182 example the way a list in target\_defaults interacts with the same named |
| 183 list in the target itself) with a couple of special characters, which |
| 184 are covered in [Merge |
| 185 Basics](InputFormatReference#Merge_Basics_(=,_?,_+).md) and [List |
| 186 Filters](InputFormatReference#List_Filters.md) on the |
| 187 InputFormatReference page. |
| 188 |
| 189 ### configurations |
| 190 |
| 191 `configurations` sections may be found within `targets` or |
| 192 `target_defaults` sections. The `configurations` section is a list of |
| 193 dictionaries specifying different build configurations. Because |
| 194 configurations are implemented as lists, it is not currently possible to |
| 195 override aspects of configurations that are imported into a target from |
| 196 a `target_defaults` section. |
| 197 |
| 198 NOTE: It is extremely important that each target within a project define |
| 199 the same set of configurations. This continues to apply even when a |
| 200 project spans across multiple `.gyp` files. |
| 201 |
| 202 A configuration dictionary may contain anything that can be found within |
| 203 a target dictionary, except for `actions`, `all_dependent_settings`, |
| 204 `configurations`, `dependencies`, `direct_dependent_settings`, |
| 205 `libraries`, `link_settings`, `sources`, `target_name`, and `type`. |
| 206 |
| 207 Configuration dictionaries may also contain these elements: |
| 208 |
| 209 |:---------------------|:----------------------------------------------------| |
| 210 | `configuration_name` | Required attribute. The name of the configuration. | |
| 211 |
| 212 ### Conditionals |
| 213 |
| 214 Conditionals may appear within any dictionary in a `.gyp` file. There |
| 215 are two tpes of conditionals, which differ only in the timing of their |
| 216 processing. `conditons` sections are processed shortly after loading |
| 217 `.gyp` files, and `target_conditons` sections are processed after all |
| 218 dependencies have been computed. |
| 219 |
| 220 A conditional section is introduced with a `conditions` or |
| 221 `target_conditions` dictionary keyword, and is composed of a list. Each |
| 222 list contains two or three elements. The first two elements, which are |
| 223 always required, are the conditional expression to evaluate and a |
| 224 dictionary containing settings to merge into the dictionary containing |
| 225 the `conditions` or `target_conditions` section if the expression |
| 226 evaluates to true. The third, optional, list element is a dictionary to |
| 227 merge if the expression evaluates to false. |
| 228 |
| 229 The `eval()` of the expression string takes place in the context of |
| 230 global and/or local dictionaries that constructed from the `.gyp` input |
| 231 data, and overrides the `__builtin__` dictionary, to prevent the |
| 232 execution of arbitrary Python code. |
| 233 |
| 234 ### Actions |
| 235 |
| 236 An `actions` section provides a list of custom build actions to perform |
| 237 on inputs, producing outputs. The `actions` section is organized as a |
| 238 list. Each item in the list is a dictionary having the following form: |
| 239 |
| 240 |:--------------|:-------|:-----------------------------| |
| 241 | `action_name` | string | The name of the action. Depending on how actions are
implemented in the various generators, some may desire or require this property
to be set to a unique name; others may ignore this property entirely. | |
| 242 | `inputs` | list | A list of pathnames treated as inputs to the custom a
ction. | |
| 243 | `outputs` | list | A list of pathnames that the custom action produces.
| |
| 244 | `action` | list | A command line invocation used to produce `outputs` f
rom `inputs`. For maximum cross-platform compatibility, invocations that requir
e a Python interpreter should be specified with a first element `"python"`. Thi
s will enable generators for environments with specialized Python installations
to be able to perform the action in an appropriate Python environment. | |
| 245 | `message` | string | A message to be displayed to the user by the build sy
stem when the action is run. | |
| 246 |
| 247 Build environments will compare `inputs` and `outputs`. If any `output` |
| 248 is missing or is outdated relative to any `input`, the custom action |
| 249 will be invoked. If all `outputs` are present and newer than all |
| 250 `inputs`, the `outputs` are considered up-to-date and the action need |
| 251 not be invoked. |
| 252 |
| 253 Actions are implemented in Xcode as shell script build phases performed |
| 254 prior to the compilation phase. In the Visual Studio generator, actions |
| 255 appear files with a `FileConfiguration` containing a custom |
| 256 `VCCustomBuildTool` specifying the remainder of the inputs, the outputs, |
| 257 and the action. |
| 258 |
| 259 Combined with variable expansions, actions can be quite powerful. Here |
| 260 is an example action that leverages variable expansions to minimize |
| 261 duplication of pathnames: |
| 262 |
| 263 ``` |
| 264 'sources': [ |
| 265 # libraries.cc is generated by the js2c action below. |
| 266 '<(INTERMEDIATE_DIR)/libraries.cc', |
| 267 ], |
| 268 'actions': [ |
| 269 { |
| 270 'variables': { |
| 271 'core_library_files': [ |
| 272 'src/runtime.js', |
| 273 'src/v8natives.js', |
| 274 'src/macros.py', |
| 275 ], |
| 276 }, |
| 277 'action_name': 'js2c', |
| 278 'inputs': [ |
| 279 'tools/js2c.py', |
| 280 '<@(core_library_files)', |
| 281 ], |
| 282 'outputs': [ |
| 283 '<(INTERMEDIATE_DIR)/libraries.cc', |
| 284 '<(INTERMEDIATE_DIR)/libraries-empty.cc', |
| 285 ], |
| 286 'action': ['python', 'tools/js2c.py', '<@(_outputs)', 'CORE', '<@(core
_library_files)'], |
| 287 }, |
| 288 ], |
| 289 ``` |
| 290 |
| 291 ### Rules |
| 292 |
| 293 A `rules` section provides custom build action to perform on inputs, producing |
| 294 outputs. The `rules` section is organized as a list. Each item in the list is |
| 295 a dictionary having the following form: |
| 296 |
| 297 |:------------|:-------|:-----------------------------------------| |
| 298 | `rule_name` | string | The name of the rule. Depending on how Rules are imple
mented in the various generators, some may desire or require this property to be
set to a unique name; others may ignore this property entirely. | |
| 299 | `extension` | string | All source files of the current target with the given e
xtension will be treated successively as inputs to the rule. | |
| 300 | `inputs` | list | Additional dependencies of the rule. | |
| 301 | `outputs` | list | A list of pathnames that the rule produces. Has access
to `RULE_INPUT_` variables (see below). | |
| 302 | `action` | list | A command line invocation used to produce `outputs` fro
m `inputs`. For maximum cross-platform compatibility, invocations that require
a Python interpreter should be specified with a first element `"python"`. This
will enable generators for environments with specialized Python installations to
be able to perform the action in an appropriate Python environment. Has access
to `RULE_INPUT_` variables (see below). | |
| 303 | `message` | string | A message to be displayed to the user by the build syst
em when the action is run. Has access to `RULE_INPUT_` variables (see below). | |
| 304 |
| 305 There are several variables available to `outputs`, `action`, and `message`. |
| 306 |
| 307 |:---------------------|:------------------------------------| |
| 308 | `RULE_INPUT_PATH` | The full path to the current input. | |
| 309 | `RULE_INPUT_DIRNAME` | The directory of the current input. | |
| 310 | `RULE_INPUT_NAME` | The file name of the current input. | |
| 311 | `RULE_INPUT_ROOT` | The file name of the current input without extension. | |
| 312 | `RULE_INPUT_EXT` | The file name extension of the current input. | |
| 313 |
| 314 Rules can be thought of as Action generators. For each source selected |
| 315 by `extension` an special action is created. This action starts out with |
| 316 the same `inputs`, `outputs`, `action`, and `message` as the rule. The |
| 317 source is added to the action's `inputs`. The `outputs`, `action`, and |
| 318 `message` are then handled the same but with the additional variables. |
| 319 If the `_output` variable is used in the `action` or `message` the |
| 320 `RULE_INPUT_` variables in `output` will be expanded for the current |
| 321 source. |
| 322 |
| 323 ### Copies |
| 324 |
| 325 A `copies` section provides a simple means of copying files. The |
| 326 `copies` section is organized as a list. Each item in the list is a |
| 327 dictionary having the following form: |
| 328 |
| 329 |:--------------|:-------|:------------------------------| |
| 330 | `destination` | string | The directory into which the `files` will be copied.
| |
| 331 | `files` | list | A list of files to be copied. | |
| 332 |
| 333 The copies will be created in `destination` and have the same file name |
| 334 as the file they are copied from. Even if the `files` are from multiple |
| 335 directories they will all be copied into the `destination` directory. |
| 336 Each `destination` file has an implicit build dependency on the file it |
| 337 is copied from. |
| 338 |
| 339 ### Generated Xcode .pbxproj Files |
| 340 |
| 341 We derive the following things in a `project.pbxproj` plist file within |
| 342 an `.xcodeproj` bundle from the above input file formats as follows: |
| 343 |
| 344 * `Group hierarchy`: This is generated in a fixed format with contents |
| 345 derived from the input files. There is no provision for the user to |
| 346 specify additional groups or create a custom hierarchy. |
| 347 * `Configuration group`: This will be used with the |
| 348 `xcode_config_file` property above, if needed. |
| 349 * `Source group`: The union of the `sources` lists of all `targets` |
| 350 after applying appropriate `conditions`. The resulting list is |
| 351 sorted and put into a group hierarchy that matches the layout of |
| 352 the directory tree on disk, with a root of // (the top of the |
| 353 hierarchy). |
| 354 * `Frameworks group`: Taken directly from `libraries` value for the |
| 355 target, after applying appropriate conditions. |
| 356 * `Projects group`: References to other `.xcodeproj` bundles that |
| 357 are needed by the `.xcodeproj` in which the group is contained. |
| 358 * `Products group`: Output from the various targets. |
| 359 * `Project References`: |
| 360 * `Project Configurations`: |
| 361 * Per-`.xcodeproj` file settings are not supported, all settings are |
| 362 applied at the target level. |
| 363 * `Targets`: |
| 364 * `Phases`: Copy sources, link with libraries/frameworks, ... |
| 365 * `Target Configurations`: Specified by input. |
| 366 * `Dependencies`: (local and remote) |
| 367 |
| 368 ### Generated Visual Studio .vcproj Files |
| 369 |
| 370 We derive the following sections in a `.vcproj` file from the above |
| 371 input file formats as follows: |
| 372 |
| 373 * `VisualStudioProject`: |
| 374 * `Platforms`: |
| 375 * `ToolFiles`: |
| 376 * `Configurations`: |
| 377 * `Configuration`: |
| 378 * `References`: |
| 379 * `Files`: |
| 380 * `Filter`: |
| 381 * `File`: |
| 382 * `FileConfiguration`: |
| 383 * `Tool`: |
| 384 * `Globals`: |
| 385 |
| 386 ### Generated Visual Studio .sln Files |
| 387 |
| 388 We derive the following sections in a `.sln` file from the above input |
| 389 file formats as follows: |
| 390 |
| 391 * `Projects`: |
| 392 * `WebsiteProperties`: |
| 393 * `ProjectDependencies`: |
| 394 * `Global`: |
| 395 * `SolutionConfigurationPlatforms`: |
| 396 * `ProjectConfigurationPlatforms`: |
| 397 * `SolutionProperties`: |
| 398 * `NestedProjects`: |
| 399 |
| 400 ## Code Location |
| 401 |
| 402 Here! http://gyp.googlecode.com/ |
| 403 |
| 404 ## Group Members |
| 405 |
| 406 |:-----------------|:---------------------------------| |
| 407 | Darin Fisher | Overall approval of final design | |
| 408 | Elliot Glaysher | Approval of Linux build functionality. | |
| 409 | Alex Harper | | |
| 410 | Steven Knight | Language specification.<br />Code for generating Scons file
s from `.gyp` files. | |
| 411 | Mark Mentovai | Input language design and implementation.<br />Code for gen
erating Xcode files from `.gyp` files.<br />Approval of Mac (Xcode) build functi
onality. | |
| 412 | Bradley Nelson | Code for generating Visual Studio files from `.gyp` files.
| |
| 413 | Randall Spangler | | |
| 414 | Nicolas Sylvain | Approval of Windows build functionality. | |
| 415 |
| 416 ## Caveats |
| 417 |
| 418 TODO(sgk): Notes/Question from very first prototype draft of the language. |
| 419 Make sure these issues are addressed somewhere before deleting. |
| 420 |
| 421 * Libraries are easy, application abstraction is harder |
| 422 * Applications involves resource compilation |
| 423 * Applications involve many inputs |
| 424 * Applications include transitive closure of dependencies |
| 425 * Specific use cases like cc\_library |
| 426 * Mac compiles more than just .c/.cpp files (specifically, .m and .mm |
| 427 files) |
| 428 * Compiler options vary by: |
| 429 * File type |
| 430 * Target type |
| 431 * Individual file |
| 432 * Files may have custom settings per file per platform, but we probably |
| 433 don't care or need to support this in gyp. |
| 434 * Will all linked non-Chromium projects always use the same versions of every |
| 435 subsystem? |
| 436 * Variants are difficult. We've identified the following variants (some |
| 437 specific to Chromium, some typical of other projects in the same ballpark): |
| 438 * Target platform |
| 439 * V8 vs. JSC |
| 440 * Debug vs. Release |
| 441 * Toolchain (VS version, gcc, version) |
| 442 * Host platform |
| 443 * L10N |
| 444 * Vendor |
| 445 * Purify / Valgrind |
| 446 * Will everyone upgrade VS at once? |
| 447 * What does a dylib dependency mean? |
| 448 |
| 449 ## Testing Plan |
| 450 |
| 451 _What are the sub-units of your system that will be independently testable? |
| 452 Tests must be approved by the code reviewer, and must follow the guidelines in |
| 453 the unittesting document as far as possible. See What Is A Design Document for |
| 454 criteria for whole system tests on servers. If there are changes envisaged in |
| 455 your future work, would your tests verify the base functionality? If some of |
| 456 your tests cannot be easily automated (e.g. UI tests), how will you document |
| 457 the needed special procedures?_ |
| 458 |
| 459 ## Documentation Plan |
| 460 |
| 461 Documentation via this wiki: http://code.google.com/p/gyp |
| 462 |
| 463 ## Work Estimates |
| 464 |
| 465 _Estimates of how long each phase will take (please be detailed; subtask |
| 466 granularity should be roughly one week)_ |
| 467 |
| 468 ## Launch Plans |
| 469 |
| 470 _What are the launch plans for your project? This includes, but is not limited |
| 471 to: |
| 472 * What visible changes your project will cause on the site. |
| 473 * What will be the impact on production and/or search partners. |
| 474 * What new servers will be introduced. |
| 475 * Rough timeline for releasing your project._ |
OLD | NEW |