[Zope3-dev] RFC: Release cycles

[Roger Ineichen]

Stephan Richter wrote:
> Cc: Philipp von Weitershausen
> Subject: Re: [Zope3-dev] RFC: Release cycles
> 
> 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.

I think we get to a state where we can contribute to the
zope3 repos and help with some parts. Because we have 
projects where have to get productive till the end of 
the year.

This I think, is the best motivation for to fix bugs ;-)

> What do you think? 

1+
Great, I like such a concept. This whould be a good way for to
commit to the zope repository and there is a clear timeframe
for to get the commited packages back for to use in a release.

I think there is also a good chance to win people for to
work on the different parts if we have such clear concept.

BTW;
I have a speech at the DZug meetig exactly about such 
important concepts which makes a opensource framework 
unnuseable for bigger project if they not clear. 

Regards
Roger

> Regards,
> Stephan
> -- 
> Stephan Richter
> CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
> Web2k - Web Software Design, Development and Training
> _______________________________________________
> Zope3-dev mailing list
> Zope3-dev at zope.org
> Unsub: 
> http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch
> 
>