Featured Alpha 9 is released and likely the final one using our engine at v1!

[Cervator]

This release contains most the stuff that came in during GCI 2017 and then some. Immediately after this we're beginning to merge things into the engine for v2.0.0 that are not guaranteed to be backwards compatible: our first new major release (for about two years?) since we adopted SemVer. That includes the two large GSOC 2017 projects Sectorsand the Behavior Tree overhaul, along with some smaller but breaking changes that needed a major release.

For all the details on Alpha 9 see the Release page on GitHub

There is also a GitHub project board covering "known issues" and other recent or otherwise relevant seeming things as of the Alpha 9 release. Been trying to confirm and get updates on some of those.

IMPORTANT NOTE: As the engine (and embedded modules) get incremented to v2.0.0 things that previously depended on v1.x.y will fail to satisfy their dependencies in some cases. This is because some places only consider the very latest available dependency from Artifactory, and v2.0.0 will be too "new" to be acceptable. I'll be bulk-submitting a pile of dependency tweaks to module.txts all over the place soon, so many workspaces will need updates. It may not even be something sticking to the engine master branch will keep you safe from (it's Alpha and we need to finish some more release management and related automation!)

To better do that I've created a fresh new module mega-workspace with a grand 137 added modules and did so using a neat new way to do so thanks to the work on the new Groovy-based utility scripts (with more coming!). Simply copy paste the values from the Omega distro prop file and bulk replace the commas with single spaces. Then paste that after "groovyw module get" and hit enter! Maybe we can add another utility command for that.

Note that the Groovy utility is still "incubating" so to say and may change in a major way, bugs are also likely. It would be nice with a few more people keeping mega-workspaces for testing engine PRs (to see if modules are impacted) until the build system goes supercharged. I suggest keeping it separate and purely for testing/merging PRs. And to look up the "update-all" utility command

In the near future I may also try to submit the next stage of the Gradle overhaul plus we may tweak library dependencies and all sorts of things while we're outside of the API freeze so to say. For the next 2-3 months I expect we'll be stabilizing the develop branch and firming up the v2 API. Many things will break and then they'll be fixed! It will be glorious, but prepare to update workspaces a bit more than usual

Keep track of the v2.0.0 milestone on GitHub and probably a project board or two

In other random news Mike K found us in a book! It is kinda old and mainly about Minecraft, but hey, cool

 

[Cervator]

The v2.0.0 version bump has been applied to the engine repo and about 80 module repos that had a dependency on Core. Decently confident that'll avoid any dependency issues - for now. Unless we have some stealthy third party module development communities hiding out there anyway.

Developers: Start your Git clients! Going with the engine workspace update you'll likely want to try updating all local modules as well, unless you happen to know for sure none of them depend on Core. Protip:

groovyw module update-all

That should in theory fetch + pull for every non-embedded module in a Terasology workspace. However it may be vulnerable to pending changes you have locally or non-default branches set for specific modules. I've tweaked a few older module repos where develop was the default branch, setting everything I notice to master.

In theory that's a temporary state until module release management is properly enabled, at which point develop becomes default again so all PRs go there, consistent module super-builds work well, and so on.

Much more to do in that area, but I'm applying little non-breaking things when I have a chance. For instance in this round of changes I also took off "-SNAPSHOT" for every module dependency I could find - Gradle ignores that anyway and in an ideal future you should never depend on a snapshot dependency anyway.

We also have a ton of subtle variants in how different devs write the dependency blocks in JSON for the module.txt files. While I'm not declaring a standard yet (wish I had magic powers to configure an IntelliJ code reformatter for this) I've applied a consistent setup to every modified module that looks somewhat condensed. Example (from LightAndShadow):

"dependencies" : [
    {"id" : "Core", "minVersion" : "2.0.0"},
    {"id" : "Pathfinding","minVersion" : "0.2.0"},
    {"id" : "LightAndShadowResources", "minVersion" : "0.2.0"},
    {"id" : "StaticCities", "minVersion" : "0.2.0"},
    {"id" : "ItemRendering", "minVersion" : "1.0.0"}
],

Looking at that I'm tempted to have an auto-formatter actually put the "minVersion" first as it'll always be the same number of characters, meaning the module id coming after would still line up perfectly ... hmm!