The full release notes can be found here.
The 17 percent represents 71 bug fixes that would’ve likely been overlooked if not for the efforts of the Magento community. This result was thanks in no small part to plenty of Contribution days and hackathons, improved GitHub management, and the tireless effort of the Community Engineering team.
At Meet Magento Sweden, I was fortunate enough to participate in the Contribution Day in Stockholm.
— Max (@maksek_ua) May 29, 2017
However, this is far less about singing my own praises and more about highlighting the process behind its approval and eventual inclusion. The issue in question had the “Up for Grabs” label, which means pretty much what you’d think – anyone can take a shot at resolving an issue that was already tagged by the Community Engineering team.
After writing and testing the code, I showcased the new feature during the allotted demo time at the end of Contribution Day, then submitted the pull request (PR) to the develop branch for the upcoming Magento 2.2.
As we speak, there are other branches in use, and the develop branch always used as the integration branch for upcoming releases. For example, 2.3-develop will point to the 2.3.x releases, 2.2-develop pointed to 2.2.x, and so on.
Usually, once the pull request is submitted, someone from the Community Engineering team checks the submission, asks for more input if needed, and, if and when it’s ready, approves it for merging. The team uses self-explanatory labels to identify the status of each pull request, and is intended to keep things user-friendly and transparent.
If you’re curious about Magento Open Source, I recommend starting with the Magento Issue gates to fully understand how issues and PRs are labeled. After that, head to the Magento automated testing standards and the Magento Code of Conduct so we all can get along on GitHub while working together to achieve great things!Posted in: Magento