KnowledgeTree Blog

Can’t see the wood for the trees?

KnowledgeTree is well over 5 years old now and we have learned a lot from our users about what they require and value in a Document Management System. We have addressed many of these requirements and embraced many of these values over the years. However some requirements and values have remained frustratingly out of our reach.

KnowledgeTree has been lucky enough to have a succession of highly skilled and forward looking architects and developers to whom we owe much of the current ease of use and solid extensible core code. However, along with any mature software product there comes a level of technical debt, functional dead ends and general confusing clutter. Tools and techniques are just different today to what they where yesterday. Thankfully that level is not very high for KnowledgeTree, but it is high enough to hinder us achieving some of our goals for the product. We would like to embrace the true Web 2.0 type user interface with all it’s ajaxified ease of use and responsiveness. We would like to squeeze every ounce of performance out of the latest protocols, third-party applications, operating systems and hardware. We want to make KnowledgeTree easy and fun for community developers of all skill levels to customise, extent and generally tinker with. We would like to do all this in an environment that puts quality first by respecting coding standards and encouraging the development of testable code.

In an effort to realise these goals we have embarked on a refactoring drive that targets areas of KnowledgeTree that are hindering us achieving these goals. We are constantly refactoring KnowledgeTree in our usual day-to-day development but this refactoring drive targets much larger areas than normal and actually will effect the external behaviour of KnowledgeTree. The actual refactoring areas deserve their own blog entry and I am not going into them here. Rather I want to touch on an important tool we use to manage the process. The tool is Version Control and in our case it’s Subversion. We use the concept of development(DEV) and stable(STABLE) major code trunks in the SourceForge code repository. The refactoring drive will result in a larger divergence of the DEV and STABLE trunks for a while. This could cause some confusion so I would like to shed some light on how we will be using the SourceForge code repository trunks and branches.

The major structure we use is as follows…

- trunk
- branches
- tags
- STABLE/trunk
- STABLE/branches
- STABLE/tags

As we are approaching a release we reach a point known as “feature freeze“. At the feature freeze the current root trunk (which we call DEV trunk) is merged across to STABLE/trunk (which we call STABLE trunk) and simultaneously a new stable release branch is created in STABLE/branches/<release-version> (which we call RELEASE branch). Now the process of stabilising for the release starts.

New features and improvements that are not marked for the current version continue to be developed in the DEV trunk along with bug fixes that need to make their way into STABLE trunk and then into a RELEASE branch. STABLE trunk only has bug fixes applied to it. No new features or improvements are applied to or done in STABLE trunk. Builds are done from RELEASE branch and submitted to our QA team and an iterative stability cycle starts.

The general stabilisation workflow on KnowledgeTree pre the refactoring drive was as follows. All developers during their day-to-day activities commit new features, improvements and bug fixes to DEV trunk. Bugfixes that are marked as required by the current release are reviewed and merged from DEV trunk into STABLE trunk. They are then reviewed again as a double check and merged into the appropriate RELEASE branch. A new release is built for QA and the cycle starts again.

What the refactoring drive is going to do is introduce code that is potentially so different from the current RELEASE branch code that bug fixes in DEV trunk make no sense in the context of the RELEASE branch and visa versa. The DEV and STABLE trunks will in effect diverge completely and will only merge again when we reach 3.6 feature freeze. This means we will be forced to change our usual workflow a bit and do the current release bug fixes in the STABLE trunk and merge them into the RELEASE branch and into the DEV trunk if appropriate. This is not a big change but it does mean that STABLE trunk may not be as stable as it has been in the past. More importantly DEV trunk will proabably not be at all stable and should actually be seen as experimental.

So if you want to access the latest stable code then use the latest RELEASE branch in STABLE/branches. If you want the cutting edge code then use STABLE trunk and if you want the bleeding edge code use DEV trunk.

For example, here are the links to use in your Subversion client for the current versions…

Stable=https://kt-dms.svn.sourceforge.net/svnroot/kt-dms/STABLE/branches/3.5.2c-Release-Branch

Cutting Edge = https://kt-dms.svn.sourceforge.net/svnroot/kt-dms/STABLE/trunk

Bleeding Edge = https://kt-dms.svn.sourceforge.net/svnroot/kt-dms/trunk

You can also just explore the code and even the change log and download individual files by using the SourceForge Subversion web front end at…

http://kt-dms.svn.sourceforge.net/viewvc/kt-dms/

Have fun!