[Zope3-dev] RFC: Release cycles
Roger Ineichen
dev at projekt01.ch
Sat Oct 2 18:38:48 EDT 2004
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
>
>
More information about the Zope3-dev
mailing list