Currently, the offsider framework is at version 0.8.0 . This number is somewhat arbitrary, but the 0 major version number does mean something. Normally, this might mean that the software is buggy or otherwise unsuitable for production use. In this case, it has more to do with the stability of the API. Here is the situation as I see it:
- the software is functional, robust, and works as designed.
- It is ready for use in production systems.
- the underlying implementation is satisfactory, and will not change before version 2.0
- the API is expected to change between now and version 1.0
- it is possible that extra functionality will be added between now and version 1.0
We are moving towards a version 1.0 release. There is no timeframe for this work.
Version 1.0 will be released when the following conditions have been fulfilled:
- There has been a review of the API
- The API has been specified formally
- There is a test suite to validate that the API has been implemented correctly
- There is an implementation of the API, which has been validated against the test suite.
Once Version 1.0 has been released, the API will be frozen. The commitment is that any software written for version 1.0 will work for all versions up to 2.0.
The underlying implementation (ie the specific internal structure of an Offsider) will remain as it is now, and will not change at all until the release of version 2.0.
You may notice that I have not mentioned optimisation until now. That may seem rather surprising, considering how the framework has been implemented.
I have deliberately postponed any thought of optimisation until after the release of version 1.0
There are numerous reasons for making this choice, and I have written an entire rant on the subject.
My main focus right now is getting the API right. Once we have done that, we can start looking more closely at implementation issues.
In practice, what this means is that any optimisation code that is submitted to the project will not be placed into the main branch until after version 1.0. Even then, a case will need to be made, including a rigourous profiling comparison.
Nevertheless, I don't want to discourage you from thinking about or working on optimisation in the meantime. For this purpose, I will create a special branch of the project dedicated exclusively to optimisation issues. Even though nothing from this branch will make it into the main project until after Version 1.0, I do feel it is important to explore these issues sooner rather than later, because the experience will be valuable once we do turn our attention to making the framework run faster.
Optimisation work will inevitably bring up questions about the underlying implementation.
It is possible that there are changes that can be made which make a significant difference to the performance of the framework. If this is the case, then we will make that transition in version 2.0. Thus version 2.0 will signal a change to the underlying implementation.
It is to also possible that there will be API changes that reflect the implementation details.
Version 2.0 may never happen. We will need to see what transpires.
So there you have it. In a nutshell, this is the roadmap into the future:
- Gain experience in usage.
- Focus on API issues.
- Consider optimisation issues as low priority.
- Focus on optimisation issues.
- Consider implementation issues.
There are a number of other projects that are based on the Offsider framework.
Specifically, we have QueueReader, Weave and Tree.
As the Offsider API changes between now and version 1.0, we will make parallel releases for these other projects so that they keep up with the latest API changes.
(20100210 10:32:36) This page was produced using rsml. Source file was roadmap