Behind the scenes we have been working on our store getting it buttoned up and ready to launch. We are hoping to have it launched Monday the 11th. Its taken longer than we wanted to, but that is often the case when you are designing a system that is made to be expandable and comprehensive from the start. But it has been well worth the effort.
We are planning on launching the store in two phases. The first phase will consist of free open source modules. This is actually where the majority of the work has taken place. We have designed a system where we can mange the free modules quickly and easily, hopefully this will help spur the growth of free modules in our community. All a developer needs to add a free module is a properly set up Github repo and to add the repo url to the store. The store will automatically extract everything out of the repo for the module page and list it on our site. Once a module is updated in a repository, using Github webhooks it will notify our store, which will in turn update the module to the latest release. Handling the store this way allows developers to develop, without having to worry about constantly updating the store for their module changes.
At the same time this ushers in a level of transparency and community involvement. If a community member finds a bug in a module, or wants to add a new feature, it is easily added through Github. We are relying on this ease to spur growth and help foster a great module ecosystem. It will also bring dozens of high quality modules to our community as well, making merchants shops better and more dynamic.
Right now we are still implementing some changes in the format we will be using for the data in the free modules. We have made several changes over the last few days and might make a few more in the coming days. When we get everything finalized, we will release the specifications in our documentation so developers will know exactly how to design their repositories to be added to our store.
We are also considering splitting off our repository into another community repository for members that want to contribute modules, but do not want to maintain them. This is something we would like the communities input on. Would you like to see a repository of modules ported to our store that we do not actively maintain, but the community does?
“Would you like to see a repository of modules ported to our store that we do not actively maintain, but the community does?”
Yes certainly, the risk obviously is who is responsible for maintenance and compatibility. However if there is some mechanism for filtering by supported version number. E.g. Developer must state in the manifest what version of TBZ supported so the cart can then filter by compatible versions and also display the date module was last updated to help merchants make informed choices.
So module is known compatible with 1.0.4, tbz 1.0.5 released persons who already have it installed can verify that it works when they upgrade, if it does since it’s github someone can edit the manifest to reflect 1.0.5 compat and new users can install without question.
If no users bother with that (updating the manifest) then the backoffice only displays (filters) compatible modules and merchants can override the filter to show modules compatible with past versions.
So if i’m running 1.0.5 it will only show modules explicitly listing 1.0.5 compatibility and i can override that if necessary. Gives a good balance between shielding new merchants and allowing veterans the flexibility to do what they want.