[Zope3-dev] Zope 3 release planning

[Jean-Marc Orliaguet]

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?
>
>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.
>
>- The word of a release usually reaches beyond the Zope community, which means 
>exposure.
>
>- There is a sense of a milestone that has a well-defined set of features and 
>API.
>
>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!"
>
>Regards,
>Stephan
>  
>


Hi!

at this juncture, when people are starting to dwelve into Zope3 I would 
say that stability is more important. It is important to know when 
developing an application  whether bugs are coming from the underlying 
framework or from the application being developed. With Zope2.7 you can 
just copy the error message and paste it on Google to see what's wrong. 
I have tried that with Zope3 and it does not work as well yet.

regards /JM