This is the place where you can find the releases of The Good suite. The versioning system used follows Semantic Versioning. Since we are at the moment below version 1.0.0, this means that the public API is not yet stable and anything can still change. Since the APIs are so unstable and working with it is stilll quite verbose (you'll need a whole lot of boilerplate code, for example), the use of The Good Suite can't be recommended yet.
The APIs that make up The Good Suite seem to finally be more or less stable. The datatype files, which were the one major issue in the previous release have had a major overhaul and no more changes are planned to it at the moment. This means that no backwards incompatible changes are planned at all. However, this is still a 0.x version and if the need arises, anything - including public APIs - can be changed.
datatype. This has several consequences. The first is that the name of the datatype is now contained in the datatype file, instead of living only in the code that initiates the compilation. This removes some of the "magic" that was happening and moves the datatype name to a much better place. A second consequences is that because the datatype is now delimited by braces, more than one datatype can be in a single file. This is generally not best practice, but it does remove arbitrary limitations by the system and gives the options to the user, which is where I believe they should lie. This syntax is inspired by a C-like programming languages and is what reduced some of the reliance on whitespace and what inspired the next change.
The third (pre-)release version of this software can be found as a download on this site and as a tag on GitHub. As with the previous versions, it comes with a big red warning label instead of documentation (as there is none of the latter yet) and for the version from the site, it is assumed you can handle a lzma-compressed .7z (after all, otherwise tyiou shouldn't be using this unstable software). Everything that's not in the archive can be found on Github.
The situation in API stability is more or less the same as with version 0.2: the type definition files are the only ones still completely in the dark. Most of this version's changes were to Good Looking and its API, but they were all additions. The Good Service generated classes actually took a step forward, as they are now backwards compatible with v0.2 and v0.1. There is a new API: the FunctionHandler API, which allows you to register functions to Good Looking. However, it was designed with an eye to the future, so it's presumed to be more or less stable. One big change that is still ahead of us is the caching for Good Looking and it might cause some backwards incompatibilities, but I do not see which yet, so it's hard to predict what the exact effects will be
Though this is the second release of the software, it's still not anywhere near a stable version. For those that want to use it anyway, it can be downloaded from this site or found as a tag on GitHub. It should be noted that there is no documentation, making it really hard to work with this. As with the previous version, some additional details have been left out from our download and it's a .7z. Everything else can be found on GitHub.
Since version 0.1, stability of APIs has increased considerably. The biggest winner is probably the Good Looking templating language. It has had a large overhaul and is now rather stable. Though some major additions to it are still planned, none of the planned additions are backwards incompatible.
The other major change is in the Good Service generated classes. These should also be mostly stable now, which finally makes them sort of usable. Interestingly, plans for the future include a change that makes them compatible with v0.1 and v0.2 (which are not compatible with one another).
The only completely unstable API left is that of the type defintion files. They still have a number of changes planned and while most of them probably won't be backwards incompatible, the name of a type is currently still specirfied in the calling code only, and the plan is to move this into the type definition files, which is not backwards compatible.
This is the very first release of The Good Suite. It can be downloaded here or found as a tag on github. The release version is rather simple, using a .7z format (lzma compression). It was decided that if you aren't able to handle this file format, you're probably better off not using such an unstable API anyway and should wait for a better release instead. The release from this site also does not include empty modules, description files for the modules, extra materials such as UML sketches and the test suite. All of those can be found at github instead.
Unfortunately, there is no documentation or even a description of the public parts of the API yet. As such, such information can only be extracted from the tests, which can be found on github.
The most stable of our APIs is probably \Good\Memory API. However, that merely means that I expect no backwards incompatible changes, over there, I do expect a number of additions to the API to make it easier to work with. Unfortunately, you can't use this somehwat stable API without using the \Good\Service API of created objects, and that one's going to have a major backwards incompatible change in the near future: it's going from getter/setter functions to using properties.
There are two parts of the API that aren't actually part of the PHP API, but are part of the public interface of the library. The first of those is the language used in the datatype files This languge has a number of changes up ahead. Most of them are probably going to be backwards compatible, but there is one change that isn't. Namely, the name of the datatyoe, which is currently done outside the type system itself and in the PHP code, will be moved into the datatype files to keep them related things closer together.
The other "special" part of the API is the templating language, which has a major overhaul planned and is probably the part furthest from anything resembling stability. The idea is to bring this language closer to PHP, so the user won't really have to learn a new language. This will mean that many details will change, perhaps in a seemingly trivial manner.
This being the first version to be released, there isn't a changelog.