The Post GA Relationship between the GitHub and Composer Repositories (Quick Note)

I get the occasional question about the relationship between GitHub and the Composer packages.magento.com repository in Magento 2. This may be obvious to some, but I thought I would send this out as a quick clarification.

Development

First, the developer view of the world. GitHub is for exploration and contribution.

  • If a developer wants to see the past history of a feature (for example, how the code has changed between releases), they can use GitHub.
  • If they want to see future work going into the next release, they can use GitHub.
  • If they want to submit a bug fix, they can use GitHub.
  • If they want to collaborate on future features, they can use GitHub.

Production

Product sites should not be built from GitHub checked out code. When code is “released” it is copied to a Composer repository. This is the official “release version” of code. (We will tag in GitHub as well.) Official patches will also be released there.

Post Magento 2 GA (Q4 this year), the current Connect is going to be replaced with a new online store where you can find and purchase extensions. The purchase part is new to Magento 2. If you purchase an extension, it will then be available for download for your account via Composer. The goal is to have one Composer repository for all your Magento related downloads.

The current packages.magento.com is a Composer repository available today, but it is more of an experimentation platform that will be replaced by the new online store. It is a completely public repository – for example there is no ability to stop access to paid extensions today. The internal processes around pushing code to the new repository will also change. At one stage in the past, we pushed frequent builds to the Composer repository, but there were no guarantees around Semantic Versioning of packages and no upgrade guarantees – so it was all a bit contrived. At GA the rules are going to be more formal. Releases will follow Semantic Versioning rules (except probably the metapackages for CE and EE which will probably use product version numbering for the first two digits of the version number, which are controlled by marketing folks). Upgrades will be more controlled between official release levels.

Things are a little messy today unfortunately due to the Merchant Beta program, complicated by the fact that the new online store is not ready yet. This involves paid code (EE and some extensions), so cannot go on the current unprotected Composer repository. This is will be addressed when the new online store is available.

Developers can of course use other repositories as well. Magento will most likely encourage Merchants to always use the official central location as that code will have gone through any Magento verification processes. But it’s just Composer. A system integrator for example may decide to have a local Composer repository for locally developed code. Other repositories can certainly be used.

Conclusion

Basically the simple message after GA will be:

  • If you are building a production site, use the official Composer repository associated with the online store.
  • If you are a developer and want to explore, learn, or contribute, then go have a look at GitHub.

Personally, I like simple messages. They are … simple!

Disclaimer: This is my personal view and not binding – which makes it faster for me to get blog posts out.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: