[Geoserver-devel] alternating user/developer releases

Hi all,

I have had some thoughts recently about how GeoServer release policies are structured, and what types of issues and bugs typically make it into releases when.

While strolling through jira and trying to cull the number of issues for a particular release I find myself always pushing back "developer" issues. That is code cleanup and other things that directly impact the code, but not anything the user ends up seeing.

I wonder what peoples thoughts are about having alternating releases. Where even numbered releases are "feature issue" driven, and odd number releases are "code issue" driven. This would be similar in nature to how linux kernel versioning works, where even numbered releases are "stable" and odd numbered releases are "development".

When I refer to "code issues" i mainly refer to clean up and refactoring tasks. And when I say refactoring i mean refactoring, not rewriting :slight_smile:

Curious to hear peoples thoughts on this one.

-Justin

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Tough problem.

Do I read you correctly, the goal with such a cycle would be to to allow room / time for refactoring instead of always pushing these issues back ?

I'm big +1 for not pushing architecture stuff back when you're starting to feel the squeeze, but the question is if a rigid rule would unnecessarily delay other improvements? E.g. schedule a clean up of all the KML bits and pieces for a specific version, but still allow other subsystems, such as raster, to add new features. If you're doing the configuration stuff then obviously pretty much everything will be frozen.

Linux dropped the stable / developer model in 2003 when 2.6.0 was released, and Linus has not looked back. The main argument for the current process has been continuous integration, to avoid having things pile up and keep momentum going. We're also seeing this with 1.7.0, lots of bugs didn't get caught because people wait for us to say "stable" before they start testing. Either way, I think what you're proposing is the opposite of what Linux was doing. In Linux only developer releases had new features (new drivers excluded), but I've seen lots of code clean up diffs and harmonization in stable.

-Arne

Justin Deoliveira wrote:

Hi all,

I have had some thoughts recently about how GeoServer release policies are structured, and what types of issues and bugs typically make it into releases when.

While strolling through jira and trying to cull the number of issues for a particular release I find myself always pushing back "developer" issues. That is code cleanup and other things that directly impact the code, but not anything the user ends up seeing.

I wonder what peoples thoughts are about having alternating releases. Where even numbered releases are "feature issue" driven, and odd number releases are "code issue" driven. This would be similar in nature to how linux kernel versioning works, where even numbered releases are "stable" and odd numbered releases are "development".

When I refer to "code issues" i mainly refer to clean up and refactoring tasks. And when I say refactoring i mean refactoring, not rewriting :slight_smile:

Curious to hear peoples thoughts on this one.

-Justin

--
Arne Kepp
OpenGeo - http://opengeo.org
Expert service straight from the developers