Aug 2, 2011 - Juggling with Go releases

Currently there are different kinds of Go releases. First there are the full releases which are published every few weeks. Those are pretty mature and a good base for own development. Additionally there are weekly snapshots representing the bleeding edge. They are also good for development, but API changes may get in conflict with goinstalled packages. If those have a tag release this would be installed. Typically this tag corresponds with the Go release and so may lead to a compiling error. So if there are dependencies to external packages the developer has to take care if he uses the regular release or the weekly snapshot. This gets even worse when to providers of packages have a different strategy, the first one with a tag for the release, the other one without tag for the weekly snapshot. *sigh*

It gets even worse if you not only develop packages but also apps for the GoogleAppEngine. This environment has an own release cycle. So you've got to deliver your packages for a new release but you're also tight to the release of the App Engine if you want to use your own packages. Additional conflicts are programmed.

So right now I'm in a dilemma. I don't know how fast the team for the Go SDK for the App Engine will catch up with the current release. Beside that there are other aspects I'm thinking about. The GoogleAppEngine is a great environment, for sure. But there are constraints defined by the provided services and the way the App Engine is working. E.g. I can't use my TidelandEventDrivenCellArchitecture for complex event processing. So maybe I'll test how fast my current project could be migrated to the technology stack I planned first.