Status and Roadmap

My gratitude to the dotProject group, this Status and Roadmap page is based upon their policies and views. Their language was much better than what I came up with.

Release Roadmap

Release Description Date Version Status Notes
Current Alpha Level Not Determined .5a I’m still fleshing things out here
Previous None
Next Major None
Documentation Alpha Level You’re Reading It .2a Documentation is constantly updated

Release Process

The Bluewater MVC source code repository is hosted at Launch Pad.

I use their Bazaar as the code repository and management system. If you are experiencing problems with the Bazaar please refer to bazaar Problems

Major Feature Release

The plans for these, as well as an outline of the functionality are sporadically documented at our development site bluewatermvc.

Feature requests are incorporated into development schedules from suggestions from the user community, as well as structured aims which are part of the administrators aims for the project.

I do not respond quickly or regularly to individual feature requests. I simply don’t have enough volunteer hours to respond to each and every feature suggestion with an immediate schedule inclusion.

They are normally quickly checked to ensure that they are not an obvious duplicate and either closed (if duplicated / irrelevant or totally against the project’s core aims) or they are moved to a relevant project.

Sometimes a I may decide to pick up a feature request and implement it immediately. But that’s rare, so please don’t ask nor expect that this will happen.

For details on how to make requests, see feature_requests.

Bug Fix Releases

Bug fix versions are released on an ad hoc basis, based on the urgency of fixes incorporated, security requirements, and/or developer decision. The frequency and content of these releases is difficult to predict. Sometimes I may be hampered with considerable problems that may or may not be within the projects control – for example – the project use a third party product and libraries, meaning the fix often has to wait for resolution from the quarter before a release can be attempted.

Where possible a fix will be attached to your bug report as the report is resolved – this fix will (in all likelihood) be the php file(s) that include the fixed / adjusted code. To patch your system download the attached files and overwrite the originals on your system (REMEMBERING to back up first). Programmers, alas, are human and there may still be problems so you should be prepared to reset if the fix is inaccurate / incomplete.

For details on how to lodge see bug_reports.

Bazaar Access

As bugs are fixed the main developer Bazaar is updated. Why Bazaar? Because that is what Launch Pad gives us!

Any Bazaar-literate users are able to pull copies of the code directly from the Launch Pad repository and use that if they wish. If you are working with the Bazaar you need to be aware that it will, because it is an ongoing development environment, be subject to instability. You should approach the use of that resource with the awareness that instability is not something that we can prevent, nor will we take responsibility for as the environment is our working environment. In addition – we assume that you know how to work within a Bazaar environment. Your inability to use Bazaar should be addressed to Bazaar Documentation and not the Bluewater MVC development team, I do not/can not support/teach developers how to use the Bazaar environment.

Why No Release Dates?

Release dates are impossible to predict. I am a volunteer workforce of 1 (right now). I submit code to these updates as and when I have time available. I am actively working within this environment for a couple of live projects, so updates should be pretty regular.

Why Don’t You Release More Often?

I haven’t released anything as of yet, but this section is in anticipation of this question; having been involved with a few open source projects.

Ultimately the answer is that we release when the team feels the project is ready for release, and not for the sake of releasing anything. In my experience software released without extensive testing and a bug fixing process, early and frequent releases result in poor quality software.

As with many open source projects, I don’t anticipate a lot of user community bug reports. Projects such as this mostly get “it’s broke!, tell me how to fix it” with out much thought as to what broke, how it broke, and it brakes every time “I do this”. Therefore I am trying to do extensive UI and functionality testing. Testing is currently done by one person (me) and it takes a lot of time to write, run and confirm tests; document results; report bugs; rerun resolution testing; rerun regression testing and work through a thorough testing plan. (Anyone what to help?)

Many people equate a “Live Project” with project activity, aka: release frequency. I don’t belong in that camp. I equate project activity with the work that happens on the code + the support effort + the documentation effort.

Frequent releases may make some people happy, but it hinder others who have to take their time having to upgrade systems time and time and time again.


I understand that waiting for releases is sometimes frustrating.

Being able to accumulate the necessary time to do a proper release is an equally frustrating experience for me as well.

You can assist in this process by ensuring that bug reports are accurate, detailed and able to be duplicated. Ensuring that you do not lodge duplicated issue reports and create a paperwork load that slows things down to the point of a crawl would also be of great assistance. Ensure that you are lodging reports against the correct code base.

Better still – contribute some actual bug fixes yourself.

Do some testing and report bugs if you are not a programmer.

I’m available for commercial support as well. After all I have to feed and house my family as well. By contracting with the development team (which I hope to have grow real soon) – and not somebody from outside the group who happens to be using the project as a mere commercial opportunity – you’re actually directly supporting the project.