Almost there

The move to our new hosting provider has now been completed, with the forums and the tracker now migrated – and as an added bonus, the bug tracker is running the latest and greatest v3. It hasn’t been completely finalized just yet, so we’re seeing many of the same last issues you are, but it is being continuously updated as fixes are coming in.

We’ll do another RC before the weekend, which will hopefully be the last one. You guys are doing some awesome testing, and we’re fixing pretty much everything you report 🙂

Cheers!

Locked on!

If you’re following development of v3 closely, you may have seen a noticable increase in bugs fixed and issues closed this week. With the whole team in “get it ready”-mode, bugs are being squashed like never before. All of us in the core team are working as hard as we can to get v3 released as soon – and as bug-free as possible.

If you haven’t already done so, please take the RC for a spin, or wait for the new RC coming tomorrow. We’re closing bugs left and right these days, thanks to the effort you guys are putting into testing.

Cheers!

A bit delayed

We’re a bit behind schedule for the release candidate because of a bit of extra work needed to complete the agreed feature set for the initial release. The remaining work is about finishing the workflow implementation and features, so it is crucial that it is being completed before we can release the RC.

Unfortunately, this means the RC is being delayed, but we’re working as fast as we can to get the final issues ironed out and the rest of the workflow features finalised.

Finally! Beta 3!

We managed to take a great step up – complexity-wise – last night, as the features for creating, editing, copying and managing issue type schemes, workflows and workflow schemes was finally finished. Unfortunately I forgot to commit all my changes last night, so I will have to wait until I return home this evening to finish up the beta and release it.

Schemes?

With the much enhanced support for multiple projects in v3, and the recently added support for workflows with advanced configurations, several limitations in our implementation of issue types and issue types <-> fields settings were becoming more and more obvious. One of the biggest limitations was the fact that there was no way for a proejct to have one set of settings for its issue types and another project have its own settings. This has now been implemented by creating issue type schemes. The settings for whether or not an issue type can be reported or is at all available has now been put in a scheme, as have the settings for which issue fields are visible for any given issue type. This means you can have completely different configurations on a per-project basis, and several projects can still share configurations!

Similarly, as you may have seen with workflows, schemes have been added there as well. Schemes are how issue types relates to workflows, where one issue type will typically use one workflows, and other issue types may use other workflows. This support was also finished last night.

Finally, the restrictions for the default configurations has been implemented. That means you can no longer delete the default issue types, the default issue type scheme (this one is new), the default workflow or the default workflow scheme. This is of course to keep the bug genie working smoothly and reduce the chance of errors.

However, we’ve of course added support for copying and deleting schemes / workflows as you want, so you can still configure it to your liking – just not the default ones.

Documentation

We will need to write a lot of documentation for all of this. We’ve dedicated time for this after the RC release, which should hopefully give us enough time to give you a solid documentation base.

Oh, and btw – after the release of this beta, we will launch an updated tracker on our own site, running v3 with data imported from the main site. If you want to be invited to a test run with that tracker, let me know!

Next public beta

Just a little quick headsup regarding the next public beta. According to the previously announced release schedule, we’re a bit behind the planned dates for the beta and RC releases. We are making an extra effort trying to get the last public beta release out there before the end of this week – hopefully friday. There are a few loose ends to tie up when it comes to features that aren’t finished, but we’re getting really close.

The next beta release will be the last before the RC releases – which should happen before the end of next week, to keep the dates from slipping further.

Oh, and we have some really nice new features for you in this beta release – it will be worth the wait!

Version 3 now requires PHP 5.3.0 or higher

There has been some discussion recently as to whether version 3 should require PHP version 5.3.0 or higher, or if we should make an effort to be PHP 5.2.x-compatible. Changes made to the source code and included libraries since the first public beta was released has made PHP 5.2.x compatibility impossible, which means version 3 will require PHP version 5.3.0 or higher. This change is reflected in trunk, and will be in effect from the next beta.

On a related note – as a direct result of upgrading to PHP 5.3 functionality (mostly related to late static binding), we’ve removed over 1000 lines of duplicated code. If that’s not good news I don’t know what is.

Beta changes

For those of you following development in trunk/ directly, you might have noticed that there was quite a stir/hiccup over the weekend – and you’re very likely to experience hiccups during your day-to-day usage of the system in the coming days. Because we wanted to get the beta out instead of adding another backend update to the list of things that would postpone the beta, this upgrade has happened now instead of before the beta release. What upgrade am I talking about?

We just updated our B2DB database backend to a more advanced version which provides a lot of features we’ve been missing for a while, like a proper active record implementation, automatic object population and proper foreign objects loading. All in all a very successful upgrade, and one that has allowed us to remove ~1000 lines of duplicated code across all our classes. The best improvements are always those where you get to remove code!

What does this mean for you? Well, nothing for the previously released beta. It does, however, mean that there will be a little cleanup to do to get everything working with this updated database backend, and it will most likely mean that trunk/ will be in a fluctuating state for a few days. I’ve made sure that it installs and that you can use the frontpage, wiki, configuration page and project pages for now, and I’m cleaning up more as we progress.

Another change that is coming from this update is that the minimum required version of php is now 5.3. While we always recommend keeping your php packages up-to-date, we’ve tried to maintain php 5.2 backwards compatibility. However, with this recent database backend upgrade, php 5.3 is required. Following the discussion in our forums it was not an easy decision to make, but the move to a more capable stack of php technology has given us a lot more power to do what we want.

So, back to coding. Or sleep. Or both.