Status Information

From DotProjectWiki

Jump to: navigation, search



1 Active (2.x) Releases

Upcoming Release dotProject 2.2 - CODE UPGRADE refactoring (...still being planned) What's New - 2.2 Release Notes - 2.2 Closed Issues and Feature Requests - 2.2
Current Release dotProject 2.1.4 - SECURITY UPGRADE bug fix, XSS security issues resolved, PHP 5.3 compatibility What's New - 2.1.4 Release Notes - 2.1.4 Closed Issues and Feature Requests - 2.1.4
Current Release dotProject 2.1.3 - SECURITY UPGRADE bug fix, minor security issues resolved (...more coming...) 25th November 2009 What's New - 2.1.3 Release Notes - 2.1.3 Closed Issues and Feature Requests - 2.1.3
Previous Release dotProject 2.1.2 - PERFORMANCE UPGRADE bug fix, minor security issues resolved, performance improvements, file module update Release Date - 29th July 2008 What's New - 2.1.2 Release Notes - 2.1.2 Closed Issues and Feature Requests - 2.1.2 Test report to be provided when testing completed
Previous Release dotProject 2.1.1 - SECURITY UPGRADE bug fix and minor functionality upgrade release Release Date - 14th November 2007 What's New - 2.1.1 Release Notes - 2.1.1 Closed Issues and Feature Requests - 2.1.1 Test Report

2 Future Major Releases

Next Major Release dotProject 3.0 - Resource Management Release Date - unknown Functionality Plan and DotProject_3_Directions Release Notes - 3.0 Closed Issues / Feature Requests - 3.0
Project Budgeting dotProject 4.0 Release Date - unknown
Project Reporting & Risk Management dotProject 5.0 Release Date - unknown
Collaborative Elements & Workflow dotProject 6.0 Release Date - unknown
Documentation Major rewrite underway Estimated Release Date - first quarter 2007 This documentation site is the deliverable associated with this element. Some modules (such as Files etc) still to be completed + we will need to rework some documentation in the light of 3.x new features.

Please check System Prerequisites before attempting to install.

3 Release Process

The dotProject source code repository is hosted at

We use their CVS as our code repository and management system. If you are experiencing problems with the CVS please refer to Category:CVS Problems

Release generation checklist - see Release Checklist

We have two types of releases:

3.1 Major Feature Release

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

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.

We do not respond quickly or regularly to individual feature requests. We 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. If your feature request ends up in the Mantis listing "The Long Finger" then it's not been rejected and it has been placed on the long finger for consideration when we're planning for future releases. Once a release has been planned, relevant feature requests will be moved to a new Mantis project reflecting that feature release.

Sometimes a dev may decide to pick up a feature request and implement it immediately. That's their personal choice and we neither ask nor expect that this will happen.

For details on how to lodge see Category:Feature_Requests

3.2 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. We are often also exercised by considerable problems that may or may not be within our control - for example - we use many third party products and libraries that we often have to wait for resolutions within 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 Category:Bug_Reports

3.3 Code Repository Access

As bugs are fixed, the main developer code repositories (SVN/Git) are updated. See dotProject Code Repository for details.

Any SVN-literate users are able to pull copies of the code from SVN (for 3.0 development) at Sourceforge or Git (for 2.x development) at GitHub and use that if they wish. If you are working with the SVN or Git 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. Further to that - we assume that you know how to work with a SVN or Git environment. If you need help with SVN or Git, we recommend hunting down answers specific to those code management systems prior to posting questions to the forums.

3.4 Why No Release Dates?

Dates for releases are impossible to predict as we have a volunteer workforce who submit code to these updates as and when they have time available. As of March 2008, we do have some sponsorship for one team member to work more of less full time for a month or so on the 3.x release - but given that a lot of the workload for that conversion is currently a bit on the unknown side and we wanted to use that valuable time for real work as opposed to project planning and delivery date calculations, we currently don't have a release date for 3.x. Once we have the conversion to Zend to the point where it is ready for technology review then we will announce that on the admin blog -

In general we try to separate the support and bug fixing load from the development load this is not always feasible with a small team. We have a small development team on purpose as our last attempt at having multiple submissions from a large number of developers, frankly, lead to project chaos, feature creep and a significant nightmare to maintain and manage.

At the time that we plan a feature release we consider all feature suggestions lodged by community members. You will receive feedback on those feature suggestions via the bug reporting system ( on an ad hoc basis.

To follow the status of the current release being worked on you can track things at

or follow the commits at

4 Why Don't You Release More Often

Ultimately the answer is that we release when there is something that is ready for release and not for the sake of releasing anything. We have also found, in later years, that without an extensive testing and bug fixing process, early and frequent releases result in poor quality software. We don't get a lot of user community bug reports, and we have found that we must supplement them with our own extensive UI and functionality testing. Testing is currently done by one person 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.

We're more than aware that some people equate project activity with frequent releases. We happen to not be in that camp. We equate project activity with the work that happens on the code + the support effort + the documentation effort. We are also aware that if you release frequently you make some people happy and others, who constantly find themselves having to upgrade systems time and time and time again - grumpy. So again, rock and a hard place and we'll never please everyone no matter what we do.


We 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 us.

You can assist us in this process by ensuring that bug reports are accurate, detailed and able to be duplicated by the programmers. Ensuring that you do not lodge duplicated issue reports and create a paperwork load that slows us down to the point of a crawl would also be of great assistance. Ensure that you are lodging reports against the correct Mantis projects (yes this will mean that you will need to learn a little about Mantis - but we don't think that is too much to expect - if you cannot drive Mantis then it might be better if you refrain from lodging reports).

Better still - contribute some actual bug fixes yourself.

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

Check and see if somebody from the development team is able to provide you with paid / commercial support. You can use the support forums to pick up a support subscription or you can make a commercial arrangement direct with somebody on the development team, if they are available. By contracting the development team and not somebody from outside the group who happens to be using the project as a commercial opportunity you're actually directly supporting the project.

6 Footnotes

    --KarenC 15:46, 31 October 2006 (EST)

    Personal tools
    System Administration