On Mar 23, 2007, at 10:28 AM, Christian Theune wrote:

Am Freitag, den 23.03.2007, 08:41 -0400 schrieb Jim Fulton:
...
Is there a roadmap somewhere?

Yes. Both in the wiki (wiki.zope.org/zope3) and on launchpad.

Care to share a URL?

It seems that something should be recorded at:

   http://wiki.zope.org/zope3/Downloads

And link it in here?



Who is in charge of the 3.4 release?

/me

Cool. :)


I want to get to the point where the packages have their own release
cycles independent of Zope 3
releases.  For example, I want to stop giving eggs 3.x releases
numbers just because the package
was included in a 3.x release.

Just to make this explicit: we've gotta stick with the version numbers
that we gave out already, right?

It's complicated. :) We have lots of choices. As long as the code for most packages actually lives in the Zope 3 svn tree, I think the version numbers have to be linked. I don't think we want to move them out of the Zope 3 tree until we have a good story for working on Zope 3 itself, although, that could be debated. We also need to worry about the (many) people who use checkouts for their own development. Getting externals for everything would be really annoying.

I expect that in the next few weeks, we (ZC) will switch to using eggs rather than checkouts. When we've managed to do that, I'll be more comfortable telling other people that they should do it. :)


Assuming that someone decides to move forward with 3.4 release sans
eggification, then I'd like to decouple the 3.4 release from the
eggification efforts.

I agree here as well. Does that mean we will not advertise the
availability of the Zope 3.4 code as eggs from the release information?

Yes. I doubt they will be truly usable as eggs anyway. Independent of the 3.4 release, I think we should avoid advertising the Zope 3 eggs until we've whipped them into shape. (So to speak ;)

- I worry that download.zope.com/distribution is too uncontrolled.

We saw what happened when I started using it at the sprint. ;) Low- tech
is good, but at least some of the current limitations are impractical
unfortunately.

They are practical for supporting current experimentation, I think, but I think we need something better to move beyond the current experimental stage.

Jim

--
Jim Fulton                      mailto:[EMAIL PROTECTED]                Python 
Powered!
CTO                             (540) 361-1714                  
http://www.python.org
Zope Corporation        http://www.zope.com             http://www.zope.org



_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to