Below is a summary of the discussion from this week’s JavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. chat (agenda, Slack transcript).
Have a topic for discussion for the next meeting? Leave a comment with a suggestion.
Administrative: Meeting Hosts
Darren Ethier @nerrad and Jonathan Bossenger @psykro have volunteered to help lead the JavaScript chat each week. Responsibilities as outlined by @adamsilverstein are: show up, announce meeting, guide conversation through agenda, end on time, create next week’s agenda. Adam will create a shared calendar and continue to coordinate the meetings.
The team is still need of volunteers to help take and publish weekly meeting notes. If you have some availability and want to get more involved in core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. JavaScript, please leave a note in the comments. Your help is much appreciated.
Team Documentation
The team discussed the various pieces of documentation about our work and where they live. We have a GitHub project with links, a Google drive folder with Agendas and a document for note takers.
Everyone agreed it would be great to have a single public page somewhere (ideally on make.wordpress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org//core) that described our work and linked to all the relevant places.
Since JavaScript is a focus and not a component, the current site structure doesn’t have a clear home for the team. Adam offered to bring up the topic at the core dev chat to ask about the best location for a new page.
NPM Package Publishing
Greg (@gziolo) summarized the current state of WordPress npm packages:
- We maintain over 70 packages on npm: https://www.npmjs.com/org/wordpress.
- We develop all the packages on GitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ in Gutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ repository: https://github.com/WordPress/gutenberg/tree/master/packages.
- The same packages are used in WordPress core and that’s why we have the release timeline tied to both release schedule of Gutenberg plugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party and WordPress core.
- We try to release to npm every 2 weeks, at the time when the new Gutenberg plugin is published.
Discussion continued around who should get access to publishing npm packages and the best way to time the releases.
Currently only a small number of people have access to publishing packages. One suggestion was to expand this to include all core committers and Gutenberg core team members who are already highly trusted contributors. No final decision was made.
Andrés (@nosolosw) published the packages for the first time recently and offered this feedback:
- It’s fairly automated, although there are parts that could see some improvement.
- Challenging when you try to backport A port is when code from one branch (or trunk) is merged into another branch or trunk. Some changes in WordPress point releases are the result of backporting code from trunk to the release branch. to
master the package’s changelogs from the release branch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch". wp/trunk . In this case, there may be conflicts.
One way to address this would be:
- At time of plugin RC One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta).: we also release the RC version of packages (this could be done by using the
next dist-tag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) or something along those lines) - At time of plugin release: we release the stable version of packages.
@nosolosw offered to look at what other projects do to come up with the best approach.
#core-js, #javascript, #meeting-notes
