[Grok-dev] a Grok 1.0 release plan

Martijn Faassen faassen at startifact.com
Fri Nov 28 11:08:29 EST 2008

Hi there,

I think we should consider calling the next release of Grok Grok 1.0. I 
would like to put us through an alpha and beta phase however, for two 

* we have a number of potentially disruptive changes we'd like to get 
some feedback on before we release.

* 1.0 pre-releases for 1.0 are good marketing. We should announce these 
loudly to get people to think about Grok.

The bigger changes I'm aware of are:

* new grokproject that uses paster and WSGI. This is done, but needs to 
be tested heavily. Existing documentation needs to be modified and we 
need 'best practices' documentation that describe how you'd actually use 
all the WSGI goodness in your application. This change is by far the 
biggest one to land in a 1.0 release. Opinions on how to manage this?

* grokcore.viewlet extraction - the extraction is done but the core 
isn't modified yet, correct? Sylvain, what's the status of that work?

* refactoring grokcore.view to support improved view inheritance. JW and 
I have been working on this.

I propose the following release plan:

monday december 15: Grok 1.0 alpha

Features: all of the above. Documentation doesn't need to be ideal yet 
for WSGI, but basic tutorial and dev notes should have been adjusted.

wednesday january 7: Grok 1.0 beta

Features: improved documentation, bugfixes based on issue tracker and 
alpha feedback.

wednesday january 21: Grok 1.0rc1 release

Features: documentation on grok.zope.org is up to date with 1.0 stuff. 
This will be identical to the release if we can get away with it.

wednesday january 28: Grok 1.0 release

Hopefully practically identical to rc1.

We will then continue with Grok 1.x development - things that I want to 
publish soon is megrok.rdb and the hurry.resource javascript/css 
resource handling framework.

We need volunteers in various roles:

* release manager. I'm hoping JW will step up again in this role.

* documentation release manager: I'd like a separate role where someone 
prepares the documentation on grok.zope.org and grok/trunk/doc for the 
release. This would be mostly a documentation editing role.

* bug manager. I'm hoping someone will step up who watches the mailing 
list, irc, and makes sure we have bug reports in launchpad, and then 
shepherds the developers to actually do something about the bugs so we 
can close them.

* PR lead: It'd be great if we had someone to write press releases and 
send them to various places.

I volunteer in the role of General Nag during the release process to 
make sure everything stays on track. :)

Feedback? Opinions? Changes to the release plan?

Some inside information for those who read as far as this: a small group 
is also going to gather in late january at my place to consider larger 
low-level changes that I'll dub "Grok 2.0". We'll do our best to see 
about introducing these changes gradually in Grok 1.x releases instead, 
though, but the idea is to open up the floor for some radical rethinking 
of some low-level bits to make the insides of Zope 3 and Grok simpler 
and easier to understand. Less firmly planned is that we're also hoping 
to gather in a bigger sprint sometime next year.



More information about the Grok-dev mailing list