The distribution build process should be fully available to anyone.

[mark-k]

The wordress build environment for each version should be specified in enough detail for third parties to be able to run a build process and get the same distribution as generated by wordress.org.

See discussion about maintaining and documenting the build environment in #24977

[nacin]

Duplicate of #24976.

[mark-k]

Reopening since #24976 was closed without providing the documentation requested here. and now we have the important automatic ltr to rtl conversion getting ready for 3.8.

Without the documentation on setting up the build environment, it will be hard for people to suggest patches for fixing rtl problem as they will have to run the build process to test them.

Yes, me and others can probably figure out what is required, but this info already exists with the core developers and I see no reason to make other people guess what is needed to be done.

[dd32]

Reopening since #24076 was closed without providing the documentation requested here. and now we have the important automatic ltr to rtl conversion getting ready for 3.8.

To be clear, you want documentation on how to convert the src to build directory via our development tools (Grunt), and not how to build a release package (a zip file) like is distributed on WordPress.org (which is what was originally thought was being asked for by a few people)?

It doesn't look like we have a grunt section in the ​Core Contribution Handbook yet.

The basic process is, a) Install Node.JS locally b) Install the Grunt package c) Run Grunt's setup process for the WordPress directory, d) Run grunt build in the WordPress directory. I do agree that needs to be documented better though, I'm just including it here as a tip for others searching until proper documentation is written.

[kpdesign]

A new section is going to be added soon to the Core Contributor Handbook that explains the new build environment and how to set it up.

[nacin]

1. ​http://nodejs.org/download/
2. Run this:

   npm install -g grunt-cli
   

3. In the directory of your SVN checkout of develop.svn.wordpress.org/trunk, run:

   $ npm install
   $ grunt
   

After this, just run grunt. (This is synonymous with grunt build.) You can also run grunt rtl which will generate the uncompressed RTL CSS for you.

npm install only needs to be done once, and then whenever new dependencies are added. grunt commands will fail when it is time to run npm install.

In addition to the handbook, a README file should be added to the root of develop.svn.wordpress.org/trunk.

Or: Check out ​http://core.svn.wordpress.org/trunk and patch that. If you patch a generated RTL file, someone will help you turn that into a patch for the corresponding LTR file. Honestly, especially for RTL, reporting bugs (and snippets of CSS, if possible) is far more useful than the patch anyway.

[mark-k]

@dd32, sorry I wasn't truly consistent but for me the practical difference is nil. you need to know what tools are used in the build process of the version being developed, and what switches are used to run them if any, and then you just maintain it for the non current versions.

@nacin. so I can't use the tools on ubuntu nor on windows? ;)
Anyway, a blanket statement about installing the latest software from a repository is wrong. Today it will give me version 0.10 and tomorrow it will be 0.11. are there any guaranties that 0.11 will be fully backward compatible to 0.10 and the build script will not break in it?

Or: Check out ​​http://core.svn.wordpress.org/trunk and patch that. If you patch a generated RTL file, someone will help you turn that into a patch for the corresponding LTR file

This will create a bottleneck of experts that will have to spend time generating and testing patches that other people could have submitted. This will escalate the more build tools are being used (LESS for example).

About the README - if it can not be indexed by google then it is not useful as no one reads documentation and when people do need documentation they turn to google and not starting to look for readme files.

[nacin]

You can use the tools on any operating system. Node is available for Windows, Linux, Mac, etc. Yes, just install the latest. npm is a package manager that will handle dependencies of the various other pieces of software (grunt, various node libraries, and various grunt libraries).

This will create a bottleneck of experts that will have to spend time generating and testing patches that other people could have submitted.

Maybe. Or maybe those people will continue to submit patches. Any new tooling will *always* increase the barrier to entry somewhat, but the benefits far outweigh the costs. In the case of RTL, this was calculated risk. We have never had a whole lot of RTL tickets open at any given time, and still don't. ​http://core.trac.wordpress.org/query?component=RTL&status=!closed. But this makes future development easier.

I'm not saying it will only be a readme. I'm saying there will also be a readme.

[netweb]

In 25117.2.diff is the same as 25117.diff with the only change being the inclusion of index.php in each of the /wp-content, /wp-content/plugins and /wp-content/themes folders for the package archives that include /wp-content.

Edit: Patch also includes updates svn:ignore and .gitignore to ignore the /packages folder.
Sidenote: The patch also displays the svn:ignore property change inline with the .gitignore file, a tweak to the Trac configuration should fix this, "whatever" that may be.

---

I've also pinged @samuelsidler about adding "Build Tools" to the Core Handbook as this is still needed.
​http://make.wordpress.org/core/handbook/

I have a good start of this for bbPress already done, copy, paste, and update and we'll get it up soonish.
​https://github.com/ntwb/bbPress/blob/master/README.md

[jorbin]

The handbook page is another piece of this, but getting the package task added will help increase our transparency.