phpGroupWare Release?

I have been thinking about how to deal with releases of phpGroupWare. For me it is a technical, procedural and political question.

Over the last few months I have been playing with Drupal a fair bit. I love Drupal. It is simple to install, skin and hack. The community is great. The website is massive and has almost anything you want about Drupal. They dog food their stuff. I have quite a few clients using Drupal for their sites, they love it. There are many cool things on technical level within Druapl too - but that would take this post off on a long tangent.

Drupal was allocated 20 summer of code places by google. phpGroupWare received 1 spot, indirectly. To me this is a sign of the popularity of the project and the level of activity within the community.

I hear you thinking, but hang on, Drupal is a CMS, phpGW is a groupware suite, compare apples with apples. Well, you see I am not trying to compare apples with apples. I am looking for good ideas about how to build a quality release.

I think Drupal have it sus’d. The have the core which is released when it is ready. They also have a stack of modules which are released when the developers feel like they are ready. This provides a lot more flexibility to all developers. Developers can prepare versions for multiple versions of Drupal, but also release stuff when they think it is ready for release, not wait for the next mega tarball to be prepared.

I think that the Drupal release model may work well for phpGroupWare. We could prepare the core (probably API, admin, addressbook, calendar, email, filemanager, notes, preferences, setup, todo - the PIM apps and sync when it is ready) and release that as phpGroupWare 0.9.18. Then modules developers would be free to package there modules and release them when they were ready. Modules which were tested and stable at the time of the official releases would be listed in the release announcements. It would mean that getting our apps site working would be important as that would be the entry point for a new ecosystem. It would also mean that if someone is working on new features for an app, they could release often, while the core would be more static and stable, in order to encourage more app development.

I don’t think that we can have a release time table for the core unless we have significantly more (paid?) resources available.

I think that covers the technical and procedural issues, the political hopefully won’t be too painful either.

The decision on what is core and what is not will need to be made early. The criteria for assessment should be made publicly available. Developers should be free to ask that their app be considered core. Being a core app is not a vital thing, apps will still be promoted if they are not core.

We could look at 4 levels of apps. Core, as discussed above. Supported, apps which meet the core app standards, but are not considered core for whatever reason. Unsupported, apps which work but do not meet the project standards for some reason (coding standards, bypassing the API, lack of docs, require patches etc). Dead, apps which are no longer maintained and other developers feel should no longer be maintained. The status of the apps would be publicly listed.

Such a model as proposed above would allow us to release a 0.9.18 core with some additional supported apps (such as ged, property, messenger, tts) a lot sooner than trying to get all the 0.9.16 tarball apps ready for release.

The only technical issue to resolve in this plan would be version control as savannah’s CVS. isn’t really designed for this model of development. I have been discussing switching to SVN with the savannah hackers, they are supportive of the idea.

I do have comments open on my blog, so feel free to leave a comment, otherwise discuss it on the dev list. I will post a summary of the comments there if I feel it is warranted.