Discussion about release process

[Jody Garnett]

Cameron hunted me down for a chat about the Documented Release Cycle.... 
included here for anyone else who wanted more.
> 5) Documented Release Cycle
> If I am adding to my list, a bug tracker is a fine requirement - but 
> one should also consider "release cycle" (something GeoTools only 
> recently aquired and is still working on).
> My reasoning is this ... it is hard to set deadlines when working with 
> open source projects.
> I would like people around the world to be able to *depend* on OSGEO 
> projects to keep to a documented release process so that those making 
> use of the projects can constrain risk and/or have an idea of when 
> features will be made available.  I admit a formal cycle (say 6 
> months) would be much better, but a release process that interested 
> parties could help along for a deadline would also work.
cameronshorter: Is this the "Documented Release Cycle" that we should 
have? http://docs.codehaus.org/display/GEOT/How+to+cut+a+release
Jody Garnett: um no I was thinking more hard core  then that ...
Jody Garnett: for instance geotools is thinking of committing to L
Jody Garnett: 1. monthly releases
Jody Garnett: 2. six month dot releases
cameronshorter: I'm not sure I agree with this.
Jody Garnett: (so there is not conflict over getting a feature into a 
release or not ... you either have it ready and passing QA checks in 
time ... or you wait 6 months)
Jody Garnett: (and use monthly releases)
Jody Garnett: at point releases to cover serious bugs I suppose.
Jody Garnett: Does that make sense? One reason Umbento is popular is 
because people can plan arround its release cycle, right now you cannot 
plan around GeoTools (or uDig).
cameronshorter: While I'd like to have periodic releases, I don't think 
all projects (Mapbuilder included) has enough developer momentum to 
provide consistant releases.
Jody Garnett: understood, but it is food for thought.
Jody Garnett: I would settle for understood release process, ie so 
people planning can know how close a release is because it is in the 
"testing and QA phase"
cameronshorter: Yes, I think it is a good idea - but I think this is the 
sort of stability that should be backed by financial backing.
Jody Garnett: so if I sum up the need "how do I tell *when* a change 
will be available in a stable release"
Jody Garnett: yep... because even if geotools is in the bug patching 
phase right now, if some project needed a stable release out .. they 
could pitch in and help out to meet their planning deadlines.
cameronshorter: I understand your point.  And even sympathise with it.
cameronshorter: I agree that a release process is a good thing - and 
worth documenting.
Jody Garnett: And it points to something projects can improve as part of 
lumping in with OSGEO ... but yes this is only a point to debate.
Jody Garnett: ah the trick would be following that documentation
cameronshorter: Someone who wants the release enough can commit 
resources to make the release happen.
Jody Garnett: suppose I should be on IRC if you have questions like this 
others may as well...
cameronshorter: probably.
Jody Garnett: you got it, and if a project has no process then I write 
it off as a project planner (I actually do this)
Jody Garnett: should we bundle up this chat and post it to the incomm list?
cameronshorter: Yes, go ahead.
cameronshorter: By the way - you might be interested in 
http://docs.codehaus.org/display/MAP/Developers+Guide
cameronshorter: I've used an IEEE Project Management Plan template as a 
guide for the components of Project Management required.
cameronshorter: Got to head off to another chat.