More than half a year ago, we did the (hurtful) step to move the JFreeReport forums to the refurbished Pentaho-Forums. At the same time, we also changed the name of  “JFreeReport” to “Pentaho Reporting”. (This change became necessary to avoid confusion between the independent JFreeChart and Pentaho’s JFreeReport.)

Are a couple of changes are waiting to happen right now:

• We will move from the SourceForge CVS repositories to the Pentaho SubVersion repositories

  • SubVersion makes it very easy to create and manage branches. With CVS, this is not always funny, especially if your commits abort half-ways during a large merge.
  • The public CVS repository at Sourceforge is awfully slow. It take ages just to check out the project. I heard many complaints about the low performance of the CVS repository, although I never encountered those problems (the developer’s repository servers are very fast) before. Now, we solve this once and for all.
  • And finally: With SubVersion, we can handle binary files a lot better. As our project has the habit of providing the libraries along with the project’s sourcecode, we have to deal with many updates of binary files on a regular base. I will be happy when I can check-in jars, images and other binary content without having to worry about corruptions to these files any more.

• We move the Bug-Trackers to the Pentaho-JIRA system

  The Bug-Trackers of Sourceforge are nice for collecting bug-information, but they lack of CVS/SubVersion integration and they have no way of marking duplicates or connected issues.

  In the future, we want to encourage the regular use of the bug-trackers. But that’s no option if these beasts are hard to use for either the end-users or the developers. I guess I can speak with the voice of all developers, when I say, that I never stick long to solutions that do not work well. I usually work around non-working systems by finding alternative solutions. During the last five years, our work-around was to use the forum to receive bug-reports and to do the follow-up work when those beasts got fixed. It worked, but it is definitely not scalable at all.

• And as final item of upcoming changes: We are going to change the version numbering schema to a less random schema.

  The previous system of having an initial version (like 0.8.7) and then adding patch-releases to it (say, 0.8.7-10, where -10 marks the release as the tenth bug-fix release) was very uncommon, uncomfortable and as a user no one really knew when a version was stable enough to be used safely.

  Therefore, starting with the “Classic-Engine” version 0.8.9 we now change the numbering schema to the well-known and well-accepted schema of having milestone releases (having the suffix “-preX” (like -pre1, -pre2, -pre3 etc), release candidates (suffix “-RCx”) and then finally a stable release (no suffix any more).

  The Classic-Engine will then evolve into Pentaho Reporting Classic Version 1.0.0. The Flow-Engine’s next release will also adapt the new schema, we will increase the version number to 1.9.x to move it out of the numbering area of the classic engine (and to make clear that the Flow-Engine will be the successor of the Classic-Engine in the future).

And to make the list of upcoming changes complete, we are currently redesigning the ‘reporting.pentaho.org’ web-site. The current web-site mostly contained outdated and misleading information (our first deadly sin) and did not provide complete information about the engines or the design tools. And an Open-Source project without an home-page can be regarded as non-existent.

So stay tuned for the end of July – this summer will be huge!