[Zope3-dev] RFC: Release cycles

[Stephan Richter]

I think that short release cycles are very good as I stated before in the 
summer. However, right now I am not seeing enough development going on to 
justify the overhead for short release cycles. 

Let' see why releases are so "expensive". 

- We need to spend time to produce the distribution files, upload them and 
send out the E-mails. This currently involves three people; Fred, Tim and me, 
since my SVN client was broken. Now that I have a new SVN version on my 
computer, I can create release archives, so that I would only need Tim's help 
for creating the Windows binary release.

- We need to support multiple branches. Note that once we release 3.1, we 
probably have to support three branches. This will put a huge overhead on 
fixing simple bugs. In fact, I think this is the largest single overhead of 
releases. Furthermore, short release cycles do not give us a lot of time to 
test features. If we find that we messed up with an implementation of a 
feature, we have to support it for a while. 

- We need people to fix the reported bugs. While the community really helped 
us with finding bugs for Zope X3.0, the fixing process was very slow and only 
very few people fixed bugs, including fairly shallow ones that many others 
could have fixed as well.

- We need people to implement features. As you pointed out, releases make only 
sense if we have changes. The problem is that most people only work on things 
they like to work on. So even if we put up a smaller feature list for a 
release, it is usually up to the very dedicated members to complete the 
generally necessary tasks. The obvious fix for this would be to make a 
release's feature list dependent on what gets implemented and not what we 
want to be implemented. For example, it might require 10 new features to 
warrant a new dot release.

I think there might be a compromise in sight. While Mozilla used to make dot 
releases every 6 weeks (now they do any release every 6 weeks, i.e. alpha1, 
beta2, ...), it only declared only some releases as stable for application 
developers. 

Here is the option that I propose:

- Release frequently dot releases for the 1-2 years, like every 8 weeks. 
Releases are determined by a date, not features desired, though a minimum of 
10 new features must be implemented and not be in experimental state.

- When we introduce a new feature, we do not fully guarantee its stability (in 
terms of the API) till the next release. This allows us to put out new 
features quickly, but still give us and our users time to test the features 
in the wild.

- From time to time, we make a dot release that introduces no new features, 
but declares all existing features as stable. We have to put some extra 
effort into supporting these very stable dot releases as they should be 
considered the foundation for everything else.

- What are the conditions for a dot release? All open bugs marked as "urgent" 
must be resolved. We will provide bug fixes for the latest dot release and 
the last very stable dot release.

I'll note that we will need at least 5 very committed developers to keep up 
with this.

What do you think? 

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training