[Grok-dev] Grok release planning and coordination
ejucovy at openplans.org
Fri Apr 18 14:05:07 EDT 2008
> * Ethan needs to release a new version of z3c.autoinclude (he's working on
Indeed, I've just released z3c.autoinclude v0.2:
As discussed on this list, this release adds a new entry-points driven
"includePlugins" directive, and renames the "autoinclude" directive to
> * I need to modify the grok and grokproject trunks to use this new
I do recommend that grok and grokproject update to this version, but I'll
note that, strictly speaking, it's not *necessary* to update the name of the
directive generated; instead of removing the old "autoinclude" directive
entirely, I've deprecated it and stated that it will be removed in a future
0.3 release. Of course, it is still best to rename it as early as possible
to minimize the impact on future users of grok and grokproject.
Incidentally, there are two known bugs with z3c.autoinclude -- it does not
successfully include nested namespace packages (foo.bar.baz), and it fails
very badly, and unpredictably, when the base package is a package (foo) when
namespace packages in its namespace (foo.bar, foo.baz) happen to be
installed, whether or not they are included. I decided not to delay the 0.2
release for these bugs, because they were both present in 0.1 as well, and I
only discovered them in the last day or two, after I'd finished the work for
0.2; over the next few days I'll be working on these bugs and will make some
bugfix releases as soon as possible.
On Fri, Apr 18, 2008 at 1:19 PM, Martijn Faassen <faassen at startifact.com>
> Hi there,
> I'll spell out my plans for Grok releases:
> * I think we should release Grok 0.12 next week. It contains some new
> features and quite a few bug fixes. It'll provide a good basis for the
> Grokkerdam sprinters who want to build stuff with Grok instead of change
> Grok itself. The one thing we need to make sure of is the use of the newest
> release of z3c.autoinclude, as this changes the ZCML directive name, and
> also needs modifications to grokproject.
> * We should then merge things so that Grok uses grokcore.component. To
> avoid disruption to the Grokkerdam sprinters who want to hack on Grok, it'd
> be great if we could do this *before* the sprint, after 0.12 is released.
> * The sprint happens. People will hack on Grok in all kind of ways.
> * At the end of the sprint, we could consider releasing a Grok 1.0 alpha.
> We need to make sure that people don't get this one by default though, but
> need to take some special action to install it. This one is optional.
> * then we proceed to 1.0 final, after the sprint. I'd be great if we could
> expand the documentation before we did a 1.0 release, but we're already in a
> good enough shape. Anyway, we can discuss 1.0 plans more later.
> The 0.12 release next week needs a bit of coordination:
> * Jan-Wijbrand offered to do the actual 0.12 release work, and I'll help
> him. We'd be happy to receive help from people, of course.
> After the release, I hope either Brandon or Philipp can merge the
> grokcore.component branch to the Grok trunk. Philipp, are you all right with
> this? You wanted to work on it some, but couldn't that wait until after the
> merge? I think the merge will be a step forward no matter what we want to
> improve afterwards.
> Grok-dev mailing list
> Grok-dev at zope.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Grok-dev