As many of you will know – especially in more recent months – our ability to get a release out in a timely fashion has diminished greatly; the 0.8.0 release was supposed to have been released early in 2011, and here we are in 2012 and still there is no sign of it! In addition to this, the 'snapshot' binary releases we started to put out also dried up – so what gives?
The responsibility for these issues lies with myself. To a large degree this is because I have been busy working on other things, and – not wanting to spend every waking moment in front of a computer screen – decided not to dedicate so much time to CEGUI.
However, I do not come here today to make excuses
Work on CEGUI has been continuing. Kulik and myself are definitely still active and working on CEGUI and it's various sub-projects, and there's been some great work contributed by members of the community. Busy times indeed!The future of releases for CEGUI
One of the main purposes of this post is to inform you all that the planned 0.8.x series of releases for CEGUI will not be happening; the recent release of 0.7.6 basically marks the end of the road for the CEGUI releases you have been used to for the past eight years.
Another purpose of this post is to state that we will instead be releasing what would have been CEGUI 0.8.0 as CEGUI 1.0.0, removing the project's 'beta' status as we do it. Much of the rest of this post basically details what that means, what it does not mean and our intended policy from here onwards.
What it does not mean
The release of CEGUI 1.0.0 will not mean that the code is inherently more stable than 0.7.x nor that we think we have all the bugs out. There's a lot of new and re-factored code that will début in the 1.0.0 release and – while that most definitely makes for improvement – the fact is that bugs in software projects of non-trivial size are somewhat inevitable. This said, the core foundations of the CEGUI code are pretty mature by now and we remain confident that at it's heart, CEGUI is fairly rock-solid (Disclaimer: although this is truly what we feel, no warranty of CEGUI's stability is given nor implied
).The 1.0.0 release will also not mean that we consider CEGUI to be done, finished or 'feature complete'. There are things that should be there that will not be there, and certain things promised over the years are still missing and remain on the TODO list. This includes – but is by no means limited to – things like a supported interface for general keyboard navigation and full and complete Unicode support. We remain committed to providing those things – but they will not appear in the 1.0.0 release.
What it does mean
Now you know that a CEGUI 1.0.0 does not mean. I suppose I'd better tell you what it does mean.
For us, one of the key parts of being out of beta, is that we can be much more rigorous when it comes to various aspects of compatibility and the way that relates to product versions. I will detail here what a version number is and our opinion of the way that release versions are supposed to work; you may then infer how so many projects get this totally wrong
- A version number generally looks like this: 1.0.0 – and this usually translates to MAJOR.MINOR.PATCH. I will cover these components in reverse order, since that gives a more natural progression.
- PATCH – We will not break your binary
A patch version should be – as you could imagine from the name, just that – a patch, fix or “sticking plaster”. The general idea here is to address bugs and other issues without breaking anything. When using dynamic linking, you should be able to replace the library binaries without needing to recompile or re-link your code. The replacement library binaries can be dropped in and everything should continue to work as it did before – except without the bugs and issues that the release addresses, of course.
For our patch releases, we will promise to not break your binaries. Because we know that mistakes happen, in the event of a mistake that breaks our promise, a subsequent release will be made in order to correct that mistake and restore binary compatibility. - MINOR - We will not break your code
Minor versions are where additions and other more substantial changes should happen – but these changes should never break existing APIs. Due to the nature of the changes that can go into a minor release, binary compatibility is not maintained. However, compatibility at the source level is maintained, and the idea is that you just need a recompile of your code, but you should never need to fix or update your code in order to for it to work with a minor release.
For our minor releases, we will promise not to break your source code. Because we know that mistakes happen, in the event of a mistake that breaks our promise, a subsequent release will be made in order to correct that mistake and restore source code compatibility. - MAJOR - Anything goes!
Major releases are for major changes. There should be no limits on the scope of changes that go into a major release. Things can move and things can break.
For our major releases, all bets are off. The developers go wild. There are no promises to be found here, my friend!
Now that's out the way, I will state that this is one of the biggest and best thing that we have on offer when the CEGUI 1.0.0 release is made. To many it will seem a small and trifling issue, but I would assure those people that this really is quite a big deal! As users of CEGUI, you will be able to tell immediately the impact that adopting a new CEGUI release will have on your project and the extent of the work, if any, you might require in order to upgrade to a given release.
Step up to the plate.
The final big change – and this has basically already happened – is that we will no longer try and be all things to all people.
CEGUI is not our project as much as it is your project. Yes, I hold the reins (somewhat tightly!), but without people using CEGUI, reporting issues and suggesting changes, this project would have died many years ago. What we desire the most for CEGUI's future is for the community to grow further and become more active and involved in the running and development of the project. You don't need to be the worlds best coder to become involved, you can also help in a support capacity, become a Wiki editor, write documentation, create packages – the list is pretty much endless.
Related to this (and as already mentioned in the 0.7.6 thread), from 1.0.0, our part of making a release will involve overseeing the development (of course) and issuing source packages. It is expected that community involvement will provide binary packages and other such things, as those things are found to be desirable by the community. We will assist by making available the project services we have access to (like the sourceforge.net download mirror network), but we will no longer be doing the lions share of the work as regards to that.
When will the release be made?
Why, when it's done, of course! There is no set date, but a release will definitely happen some time this year. Prior to a final release, there will be at least one RC release to shake out the really obvious bugs and issues that we inevitably miss by using systems tailored to our development approaches.
Support
Here I mainly speak for myself as opposed to specifying project wide 'policy'. As has been the case for most of the past year or so, it is my intention to continue to use the forum to post announcements and such, rather than trying to answer all your questions. Obviously I'm not saying that I will not answer any posts at all, but I have no intention of answering all of them (again, the community needs to step up – looking at some of the projects you guys are working on, you clearly have a handle on CEGUI, so share the knowledge, guys!). Other than this, I can be found on our IRC channel #cegui on freenode.net, though showing up there and demanding immediate answers from myself is probably not conductive to your future participation on the channel! Also be aware of time zone differences
Anyway, this has been quite a long post, so congratulations on making it to the end. If you skipped to the end, you should be ashamed of yourself and deserve no congratulations at all
CE.