[Zope3-dev] Zope 3 release planning

[Jim Fulton]

Stephan Richter wrote:
> On Thursday 17 February 2005 06:21, Martijn Faassen wrote:
> 
>>The only reproducable way I know of to do a release (sort-of) on time is
>>to *ignore* certain issues for the time being and defer them into the
>>future. You can always do a bugfix release, or, since your next release
>>is coming up in a forseeable future, just wait until the next release.
> 
> 
> Maybe it would be worth to change our release strategy to one that is like the 
> Kernel one. Let's declare odd major version numbers as unstable and make even 
> release numbers stable releases. This way, features will be released sooner.
> 
> On the other hand, this might not be necessary, since the trunk is always 
> stable. From what I know, several of the large projects use the trunk. 
> Honestly, what does a release do that the trunk does not offer, if we ignore 
> bugs and XXX statements?

Right.

> The high-quality mandate of the Zope 3 development process gives our trunk 
> more stability than many other project's releases. So what are the advantages 
> of a release?
> 
> - Developers concentrate on bug fixing instead of features.

That would be a good thing.

> - The word of a release usually reaches beyond the Zope community, which means 
> exposure.

Yup

> - There is a sense of a milestone that has a well-defined set of features and 
> API.

Yup

You missed a very important one:

- It is harder to get people to contribute if they have to wait a long
   time to get the benefits of their contribution in a release.  I find
   this extremely frustrating with Python.

> I think that all three of those are very important, but I am not sure they are 
> a reason to release prematurely. BTW, for Zope 3 we use the motto "Speed 
> kills!"

They aren't a reason to releae prematurely, They *are* a reason to
release often.  We need to do a better job of planning our work
so we can release often.  This means spending more time keeping up
with quality.  We've ignores the collector and added XXXs incuring
technical debt. This is really unacceptable.

That's water under the bridge.  We need to stop adding nw features now
and focus on getting ready for a release.

BTW, I fear we have some serious backward compatibility challenges.
We need to be a lot more explicit on what the public APIs are so we
know what out backward-compatibility contracts are.  I think this too
needs to be resolved before the next release.  I'll have more to say
on this in a separate note, hopefully within the next few days.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org