Release Planning

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
juliangb's picture

It is exciting to think that we are just a couple of bugs away from releasing an alpha of Project Management for Drupal 7.

Roadmap: https://drupal.org/node/1862286

Given this, I wanted to take this opportunity to start a discussion on how we manage releases for Project Management.

Project Management software is business critical, and users need to know that we are serious about releasing good quality, stable, trusted software.

However, I would like to follow a principle of release early, release often.

I think that by having a regular rhythm, we will help keep momentum and also minimise support requests that come about due when the -dev release is far ahead of the point release.

My proposal is that we release approximately monthly, as long as there are no known regressions since the last point release.

We would move onto beta, rc and stable releases when the requirements for those stages have been satisfied as dictated by the roadmap linked above.

  • First week of July - alpha 1
  • First week of August - alpha 2 or beta 1
  • etc ...

In order to avoid known regressions and keep stability in these monthly releases, I suggest a hold on commits for 1 week prior to a point release, apart from simple bug fixes.

I would create an issue each month explaining where we are at.

This should lead to a pattern where we can develop in patches during that time, for them to be committed immediately after a point release, and help balance the need for stability against the momentum of a regular release cycle.

Please share your thoughts!

Does this sound too formal? Too informal?

Are there other considerations that we should take into account?

Comments

Good Idea,

D34dMan's picture

As long as there are targets to achieve it keeps developers on their heels :P with smaller doable targets. This would help a lot. A monthly target sounds good to me.


On another note about deciding the direction of development...

I think it would be a good idea to keep track on use case scenario, through a feedback form maybe. Like which all modules they are using, which are the must, which functionality are good, what they think could be improved and so so .

Unlike other drupal modules, PM is a project and it would be a nice idea to gather information about what community needs and work in that direction. This includes, feedback from those who are involved in testing as well as developing too.

Maybe a flag type system where it is clearly visible to everybody involved what is the most sought after functionality and which is the least ( and spend less or no time developing it further).

Also the data ( privacy to be preserved) could be made publicly available as a report somewhere.

I wonder if this is possible with current D.O, maybe it could be in another server ( where julliangb had hosted the demo).

The activity of creating the form and maintaining it could be a volunteer project :). Dont want to sidetrack developers.

Any thoughts?

Alpha 2

Raphael Dürst's picture

Since we are now starting to migrate to the Field API, I think this would be a good time to release an alpha2 with the latest bug fixes included.

What are your thoughts on this?

@Raphael I'm fine with

juliangb's picture

@Raphael

I'm fine with altering the monthly proposal to help bigger changes such as Field API into the code (and give time for testing both in patches and once committed)...

...but we're only 10 days away from the "start of the month" regular release and I'm not sure we're ready to put Field API patches in yet - so suggest for now we stick to that schedule. We can definitely alter it if required.

@D34dMan

Sorry I missed your comment here originally. I think it would be great if we could get some more detailed information on usage, but I am not clear on how to do this.

I tried a couple of years ago to do a survey on usage of the Storm module, but didn't get enough responses to make a statistically significant result.

Perhaps we could do a survey more generally of Drupal users, asking what they need in a project management system and the pros and cons of different systems - making a commitment to publish the results in line with our open source culture to make it more of a community effort. There could be great value in that.

In the short term, we could encourage users to "follow" issues on Drupal.org, which would at least give a sense of which issues are likely to impact a greater number of people.

My site: http://julian.granger-bevan.me.
Maintainer of: Drupal PM (Project Management).
You can contribute towards my Drupal work at http://www.gittip.com/juliangb/.

You're right, we can wait

Raphael Dürst's picture

You're right, we can wait another 10 days for the next release. Maybe we can even fix another bug in the meantime. ;)

releases that support updates

potassiumchloride's picture

At what point will PM support updates from one version to the next? We are considering PM but need a system ASAP, and we need to be prepared to seamlessly run updates without having to start over with content development each time a new release comes out. For some modules, alpha releases are not expected to update smoothly from one to the next, but once a beta is out, these updates are supported.

I'm quite keen to support

juliangb's picture

I'm quite keen to support upgrades continually - and that's the way that we've operated throughout the dev stage and alpha so far.

Understandably you want to start using it and not need to start over each time.

However you need to be aware that features will change quite significantly over the course of the alpha period - particularly we are removing custom fields and replacing them with fields defined by core. There will also be some additional dependencies - thus, a little care will still be needed when upgrading through the alpha period, although your data should persist.

My site: http://julian.granger-bevan.me.
Maintainer of: Drupal PM (Project Management).
You can contribute towards my Drupal work at http://www.gittip.com/juliangb/.