[Grok-dev] Grok 1.1 the plan

[Souheil CHELFOUH]

about grokcore.content
===================

I did the tests and changes in a branch :
"http://svn.zope.org/grok/branches/grok1.1-new-grokcore/"
As I worked on it before and during the sprint, I didn't merge, not
knowing what you guys were doing.
That being said, I think that it's safe to merge.

2010/2/1 Martijn Faassen <faassen at startifact.com>:
> Hi there,
>
> Here's a plan for Grok 1.1, getting it to release.
>
> Grok 1.1 release focus:
>
> * use the Zope Toolkit as a base instead of Zope 3.4
>
> Secondary features:
>
> * new grokui.admin
>
> * extracted grokcore.model (has this landed on trunk already? don't see
> a changelog entry or entry in set.py yet)
>
> * getting rid of old style zopectl template (I think this is a change in
> grokproject)
>
> We have two plans on how to get to Grok 1.1 final. Plan A:
>
> * try to release a Grok 1.1 that doesn't depend on most zope.app.*
> packages at all. They're not needed in the path in order to be able to
> start a Grok app. We release a backwards compatibility package that does
> pull them into the path (and we maintain versions for these packages in
> zopeapp.cfg)
>
> * this means we need to detach zope.app.wsgi and zope.app.publication
> from zope.app.testing and zope.app.zcmlfiles. Along with
> zope.app.appsetup (already detached) we're going to keep these zope.app.
> packages in Grok for now. See my previous mails for more details (in the
> "losing momentum" thread, and the recent sprint report).
>
> * We might eventually choose to rename these packages to zope.wsgi and
> zope.appsetup and zope.publication (or whatever) though that doesn't
> appear necessary for us to lift the dependencies. It would just make the
> zope.app.* world clearly a world we don't need to care about anymore.
>
> Plan A depends on how much work we spend on it. We will review the
> situation by february 16, about two weeks from now. If we have made
> unsufficient progress on this topic by then, we'll go for plan B.
>
> Plan B:
>
> * release Grok 1.1 without all dependencies cut. This means we will
> effectively (through zope.app.testing and zope.app.zcmlfiles) pull in
> *all* zope.app.* packages.
>
> * We *will* depend on the ZTK however.
>
> * Grok 1.1 is however still useful as a transition. Developers can start
> to convert their code to change imports everywhere to use non zope.app.*
> as much as possible.
>
> * Grok 1.2 will then be the ZTK-less version. We'll try plan A again.
>
> Plan B is still a good plan. But I hope we'll see some more efforts to
> loosen our connection with zope.app.* in the coming weeks. The further
> we get with plan A, the better.
>
> Grok 1.2 looking forward:
>
> * we need to land the Martian inheritance changes
>
> * we need to land the grokcore.view view registry changes
>
> * Martian testing changes (the Manuel work)
>
> Regards,
>
> Martijn
>
> P.S. Thank you Souheil for making me write this plan down. It's much
> appreciated, and the clarity is really needed.
>
> _______________________________________________
> Grok-dev mailing list
> Grok-dev at zope.org
> https://mail.zope.org/mailman/listinfo/grok-dev
>