[Zope-dev] Version bumping in the trunk after release
Hi, I would propose a one word change in the "Releasing Software" document which is part of process documentation for zopetookit. After preparing a release, developer increase next version number to next feature version or next bugfix version. From the explanation given there, it is very obvious that the number should be changed to next bugfix release. I think the wording also should be changed, so that there won't be any confusion. This sentence: Back on the trunk or the release branch, increase the version number in ``setup.py`` to the *next* release while preserving the ``dev`` marker. Should be changed to: Back on the trunk or the release branch, increase the version number in ``setup.py`` to the *next* bugfix release while preserving the ``dev`` marker. If there is no objection, I am going to make this change after 3 days. To understand the context, here is the full text: 6. Back on the trunk or the release branch, increase the version number in ``setup.py`` to the *next* bugfix release while preserving the ``dev`` marker. The convention is that the trunk or release branch always points to the upcoming release, *not* the one that has been released already. So if you've just released version 3.4.1, you should change ``setup.py`` to read:: setup( name='...', version='3.4.2dev', ... ) In ``CHANGES.txt`` add a *new* section for the upcoming release. The release date for that should say "unreleased" so that committers recording their changes won't accidentally put their entry in the section for an already released version. For example:: 3.4.2 (unreleased) -- * ... 3.4.1 (2007-01-24) -- * Fixed bug in the foo adapter. * Added a bar utility for optimized kaboodling. 3.4.0 (2006-09-13) -- Initial release as separate egg. Regards, Baiju M Index: source/process/releasing-software.rst === --- source/process/releasing-software.rst (revision 109748) +++ source/process/releasing-software.rst (working copy) @@ -74,7 +74,7 @@ versions and linking models (framework / non-framework). 6. Back on the trunk or the release branch, increase the version - number in ``setup.py`` to the *next* release while preserving the + number in ``setup.py`` to the *next* bugfix release while preserving the ``dev`` marker. The convention is that the trunk or release branch always points to the upcoming release, *not* the one that has been released already. So if you've just released version 3.4.1, you ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: DateTime/trunk/src/DateTime/tests/testDateTime.py add a failing test for a regression in parsing ISO format datetimes from DateTime 2.10, as discussed at http://dev.plone.org/plone
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Aspeli wrote: > Tres Seaver wrote: >> Please don't deliberately check in failing tests on the trunk. If you >> need to do this, make a branch, and ask on the mailing list for people >> to investigate your branch. > > Why not? Trunk is (well, was) broken. This makes it clear. The > regression actually happened ages ago, but no-one had written a decent > test for the original functionality, so the regression was only > discovered in application software. This test corrects that omission, > and helped a few people co-ordinate addressing the issue. > > Why benefit do we get from not making the breakage explicit to everyone? Two things: - - Most importantly, we have a firm policy that the test should always be "clean" (passing all tests). This means that I don't have to fix the test J. Random Hacker checked in broken before doing work on an unrelated bit of code: I can run the tests before my change, apply and run them afterward, verifying that I didn't break anythin. - - You'll note that "broken" is a matter of opinion here. David actually checked in an update (before my message, but I hadn't read it yet) which indicates that. So, if you think the behavior of the trunk is broken, put your test demonstrating that breakage either on a branch or as a patch in the tracker, and ask folks here to review it. *Don't* bogart the clean build status of your trunk: checking in a breaking test is like pulling the emergency stop lever on the subway. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkuTJAoACgkQ+gerLs4ltQ5/1QCgzjMniDJ29H4FxY0g+jLK2SmL zLMAoLcuonWnoHNOdNYwn0VfBuF5ZiL5 =/oWp -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Zope-Checkins] SVN: Zope/branches/tseaver-clarify_install_docs/doc/ Split out docs for 'normal' installation from those using 'zc.buildout'.
Am 03.03.2010, 21:27 Uhr, schrieb Tres Seaver : > I recommend virtualenv to anybody who just wants to install and run the > Zope2 appserver, without needing to drink a lot of "kool-aid": just > install it from PyPI, run 'mkzopeinstance', and you're done. Note that > I specifically remomve the non-virtualenv easy_install docs: I don't > want us *ever* to encourage the use of easy_install outside a virtualenv. Thanks for the clarification. >> I thought zc.buildout is preferred by most people in the Zope community. > buildout works for *developers*: it is completely strange for people > who just want to install and run Zope. Mixing the buildout version of > the installation in with the non-buildout version was a disaster, from a > readability standpoint. I'm not sure if take up outside the Zope community is that important. I've not come across virtualenv in a non-Zope context but then I don't spend a lot of time trying out all the "cool" software out there. What is important is that people can get up and running easily and don't f*ck their systems with injudicious use of setuptools magic. The important thing, as I see it, is: "In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it." In my view neither virtualenv nor buildout are quite there. If someone can explain to me how to use virtualenv in a way that makes it easy to deploy what I've developed on another environment then I'd be happy to go that way. >> virtualenv is also puzzling if you are not familiar with it. Using >> activate and deactivate or the right paths isn't much easier to learn >> than using zc.buildout. > The environment itself is much closer to what people expect: libraries > installed under 'lib/pythonX.Y', scripts in 'bin', headers in 'include', > no funky 'parts' or 'eggs' directories, no idea that config files might > get blown away just because you update software. I know that some of > that is due to popular recipes, but that argument is specious: > buildout's value proposition derives in part from the network effect of > having those recipes available and widely used. The layout of a buildout project is indeed somewhat confusing. But the config file makes it much easier to replicate what you're doing elsewhere and I think most Zope users will be developing something locally to run elsewhere, in which case it should be made as easy as possible to replicate the experience. The only install & run users I can think of would be Plonies and they have their unified installers anyway. > Activate is a completely unnecessary attractive nuisacne: I *never* use > it, and I routinely see people who *do* use it end up running from > different environments than the ones they think they are running. +10 I thought I'd been dumped into a new shell / interactive Python the first time I saw it! >>> - - We have two alternate zc.buildout scenarios (install Zope + run >>>mkzopeinstance vs. self-contained environment). The first has no >>>real advantage over the virtualenv one, except being able to >>>run buildout to update the software (heaven help you if you forget >>>to configure the index properly!). The second leaves you without >>>the annotated config file, a *major* faux pas. >> >> I consider the self-contained scenario still as experimental. Following >> the instructions requires much more typing than the other scenarios. But >> I'm optimistic it can and will be improved. > The self-contained mode is likely *perfect* for developers who produce a > highly-customized bundle o Zope, 3rd party software, and custom code. > It just isn't right as the "first choice" for somebody installing Zope > for the first time. Who is likely to be installing Zope for the first time? Much as I love Zope, we have to acknowledge that as things stand Zope is not attractive for newbies. But this is not just about getting up and running. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope Tests: 7 OK
Summary of messages to the zope-tests list. Period Fri Mar 5 12:00:00 2010 UTC to Sat Mar 6 12:00:00 2010 UTC. There were 7 messages: 1 from Christian Theune, 6 from Zope Tests. Tests passed OK --- Subject: OK: Something that is tested From: Christian Theune Date: Fri Mar 5 07:29:00 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013683.html Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Fri Mar 5 20:36:30 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013684.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Fri Mar 5 20:38:30 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013685.html Subject: OK : Zope-2.12 Python-2.6.4 : Linux From: Zope Tests Date: Fri Mar 5 20:40:30 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013686.html Subject: OK : Zope-2.12-alltests Python-2.6.4 : Linux From: Zope Tests Date: Fri Mar 5 20:42:30 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013687.html Subject: OK : Zope-trunk Python-2.6.4 : Linux From: Zope Tests Date: Fri Mar 5 20:44:30 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013688.html Subject: OK : Zope-trunk-alltests Python-2.6.4 : Linux From: Zope Tests Date: Fri Mar 5 20:46:30 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013689.html ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
