On Jul 5, 2007, at 9:54 AM, Stephan Richter wrote:

On Thursday 05 July 2007 09:43, Jim Fulton wrote:
Specifically: Should I make it the default policy for buildout to
prefer final releases?  I think this is the right thing to do in the
long run, however, it will cause buildouts that implicitly use non-
final eggs to be downgraded.  This will cause some pain until people
make adjustments.

I am fine with this change, since I tend to do final releases more frequently than others. In other words, I trust my testing and if I did not change anything ground-breaking, I usually release a final version quickly. I can see that you are using version numbers differently, but that's fine with me

I'm not sure I am.

For smaller packages, I'm inclined to avoid non-final releases most of the time. For larger packages, most notably ZODB, I think non- final releases are needed. If a package depends on a non-final release, then the dependent package should also be non-final. So, a small packages that might not normally need non-final releases, might have to use a non-final release to be able to use a new feature in something else that has been released in a non-final form.

And for the case that I need the cutting edge, as long as you tell me the
option to use for getting the latest releases, then I am fine. :-)

I'm adding a prefer-final buildout option. The value can be either true or false. The questions is what the default should be. You can override the default either in a specific buildout or for all your buildouts (~/.buildout/default.cfg).


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

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

Reply via email to