The reason for this is that the scripts to build ocPortal were a kind of black magic. Black magic doing a lot of complex stuff and designed with a solid process behind them, but still they were really cobbled together. Over time their construction branched further away from how ocPortal itself worked.
It probably will continue to be me putting out releases in the near future, but it's a point of principle really that an Open Source project should not rely on one person. If I got hit by a tactical drone strike then new developers shouldn't have to get some old copy of the build scripts that I was good enough to remember to manually share at some unknown point in time, then update them and try and make them work again in a reliable way. The process is too complex for anyone to do that easily, and certainly rewriting them from scratch would take weeks – not a smooth fork start that many developers could stomach.
Something had to change here, so I've just spent four days redesigning the build process to be more logical and putting it inside the public github repository. I haven't just copied stuff over, I've revisited how files are put together, commented it thoroughly, and properly integrated it all into the contemporary ocPortal architecture. In particular how the build process chooses what files to include is now integrated with ocPortal's own filesystem navigation code (these were really diverging and that bothered me too).
In addition, the release platform on ocPortal.com has also been brought into github. The release platform handles various things, such as the tracker, the release database, upgrade generation, upgrade advice, the bugs database, personal demos, and automated error advice querying. Between the release platform and the build platform, and ocPortal itself, and the non-bundled addon platform, is now a consistent way of handling version naming, which again had been missing before and only solved via severe cobbling-together.
The build and release platforms are simply defined inside github as non-bundled addons, in exactly the same way other non-bundled addons are defined.
This is really nice as we now have a centralised place for all the different aspects to the ocPortal project, so that we can now keep them working together cleanly with minimal effort. Be it ocPortal itself, non-bundled addons, the build platform, or the release platform. All this without actually making anything bloated because everything is still defined in a very modular way, using the various APIs that allow definition of walls between things and communication paths. Github contains essentially a "fully modded" version of ocPortal, and the build/release/addon platforms (and other available scripts) allow refining it out however is required.
Increasingly more and more cool stuff that does not really belong in the ocPortal release, is being made available in the platform as non-bundled addons. One example I love from v9 which has only been briefly mentioned so far is our "static site exporter".
- Addons aren't strewn around and unintegrated, so users can more easily get access to stuff that is kept up-to-date and properly integrated with other components. Other CMSs usually decentralise heavily with the effect of creating a nightmare for anyone trying to get stuff to work in harmony. Some of the proprietary CMSs still integrate things too tightly and force you to continually consciously ignore features, and this opposite problem is avoided too.
- It's great that we can build in these addons without making the ocPortal releases bloated.
- It's also great that unlike some CMSs (cough Joomla, cough concrete5) we can supply high-quality addons for free (i.e. ocPortal is not effectively acting as a loss leader for sale of commercial addons, like is the case with many "Open Source" projects).
It's also great that we can develop new technologies as non-bundled addons, that maybe don't meet all our standards, and then have an easy route to moving them over to core functionality at a later date should it make sense to. In this scenario the non-bundled addons are a staging platform for future technology, and we don't have a poor choice between:
- getting things release-ready all in one go (economically unfeasible)
- or, developing things only on client projects and then unwittingly having them fork away from compatibility over time
In addition to all the above, the Code Book was rotting. It started as a Word document, then was edited in Open Office, Libre Office, Apple Pages, and Kingsoft Office, all of which have bugs or functionality holes that totally messed up document formatting over time. Therefore this has now been moved into github in neatly-marked-up Comcode format and sits neatly alongside the other documentation. A nice advantage is this can now be maintained within the development cycle with more ease – e.g. search and replaces will touch it.
So the documentation platform is fully in github now. Oh, and the rest of the testing platform has also been added, or in some cases the Code Book is now linking to where some manual test sets are stored inside our Dropbox.
- a lot of additional stuff is now Open-Sourced and third-party ocPortal developers are more empowered than ever
- the platform as a whole has stronger foundations for pushing forward hard in a way that meets our projects goal for both efficiency and simplicity