[Grok-dev] towards a release

Justin Fletcher justin at opensoft.ws
Fri Mar 7 11:25:31 EST 2008

On Fri, Mar 7, 2008 at 4:46 PM, Martijn Faassen <faassen at startifact.com>

> Hi there,
> We want to do a release soon, I think. We have two choices:
> * release the trunk as 0.12
> * release the trunk as 1.0
> What would people prefer, and why?
> I'm a bit more likely to go for 0.12 right now. Two reasons:
> * we haven't moved to the proper versions of Zope 3.4 eggs yet, my one
> 1.0 requirement.
> *  I think a "1.0" release is a great way to catch a lot of attention.
> We'll be announcing the 1.0 plans to the public, then we have a beta,
> excitement mounts, etc. I'm not sure we're quite ready to do the proper
> buildup.
> Given all that, I prefer pushing out a 0.12 soon, then move on to work
> on the version issue. Unless a volunteer steps up and fixes all the egg
> versions to KGS-based ones very soon.
> Regards,
> Martijn
> _______________________________________________
> Grok-dev mailing list
> Grok-dev at zope.org
> http://mail.zope.org/mailman/listinfo/grok-dev

I normally just lurk in this list, but I had a thought I'd like to share.
My vote is on the 0.12 release as I think good documentation should be
coupled and stabilized with each release.  I think the documentation
(examples, how-to's, etc) are in a pretty good state right now, but one of
the problems I have had with mainly Zope (and to a lesser extent Grok since
it is still very new) is finding documentation that I know works with the
release I am using.  Many times I have found a useful document describing
something I wanted to try out only to find that it it doesn't work.  As a
new user this is very frustrating as I didn't know enough about the overall
system to know why it didn't work or what could be changed to make it work.

So basically my thought is that I would like to see (in whatever is deemed
functional and maintainable) corresponding documentation with each
significant or feature changing release.  I think this will not only help
with initial exposure to Grok, but also with long-term user retention.  As
an example see the MySQL documentation.  Each significant release is
accompanied by corresponding documentation.  If I, as a user, see something
documented I know right away if it will work with the version I am running,
or if not then it can be justification for changing/upgrading.

I know it would be a difficult task that will probably require a volunteer
team, but hopefully much of the documentation could simply be copied from
release to release and only minor tweaks and updates in places.  My time is
often very limited, but I'd be willing to help in whatever way I can.

Lastly, this thought is just a basic proposal to begin discussion if there
is interest.  The only functional thought I've had at this point is to move
the existing how-to's, etc into a 0.1x subfolder to act as a
pre-1.0container so the documentation can also be prepared for a
1.0 release.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.zope.org/pipermail/grok-dev/attachments/20080307/81793502/attachment.htm

More information about the Grok-dev mailing list