[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
reasons:
* 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.
Regards,
Martijn
More information about the Grok-dev
mailing list