As Mono grows on servers, mobile and desktop platforms, we are looking to hire programmers to join our Mono Runtime team.
The Mono Runtime team owns the code generator, the just-in-time and ahead-of-time compilers, the garbage collector, the threadpool and async layers in the runtime and mostly works in the C-side of the house.
If you are a developer with low-level experience with virtual machines, just in time compilers or love garbage collection, real time processing, or you read every new research paper on incremental garbage collection, hardware acceleration, register allocation and you are interested in joining our young, self-funded and profitable startup, we want to hear from you.
Send your resumes to firstname.lastname@example.org
Posted on 18 Oct 2011
We have historically made stable releases of Mono that get branched and maintained for long periods of time. During these long periods of time, we evolve our master release for some four to five months while we do major work on the branch.
Historically, we have had done some of these large changes since we have rewritten or re-architected large parts of our JIT, or our garbage collector, or our compilers.
There were points in the project history where it took us some 9 months to release: seven months of new development followed by two months of beta testing and fixing regressions. With Mono 2.6 we tried to change this, we tried to close the release time to at most six months, and we were relatively good at doing this with 2.8 and 2.10.
We were on track to do a quick Mono 2.12 release roughly around May, but with the April bump in the road, this derailed our plans.
Since 2.10.0 was released two things happened:
Now that things have settled at Xamarin and that we are getting Mono back into continuous integration builds we are going to release our first public beta of the upcoming Mono, it will be called Mono 2.11.1. We will keep it under QA until we are happy with the results and we will then release Mono 2.12 based on this.
But after Mono 2.12, we want to move to a new development model where we keep our master branch always in a very stable state. This means that new experimental features will be developed in branches and only landed to the master branch once they have been completed.
Our goal is to more quickly bring the features that we are developing to our users instead of having everyone wait for very long periods of time to get their new features.
These are some of the new features availalable in Mono 2.11:
Posted on 14 Oct 2011