Re: [Zope3-dev] Re: faulty releases and pypi access [update]
On Sep 28, 2007, at 1:36 PM, Dieter Maurer wrote: ... Your example: You have release 1.1. You start working on the next release: 1.2dev-r#. Someone fixes a bug in 1.1 and releases 1.1.1. With quite high probability, the bug fix should go as well into the 1.2 development. Thus, the problem you describe (1.1.1 is newer than 1.2dev-r; but it treated as older then 1.2dev by 'setuptools') has an effect only for a very limited time -- the time until the fix (1.1 -- 1.1.1) went into the 1.2dev release, which would probably become some 1.2dev-r!. Sure, but that time could stretch out quite a bit. I suppose that this problem somewhat inherent in having multiple release branches. For example, whatever we do, there will always be the possibility that an x.y.z release could have fixes in it that aren't in an x.y+1 release yet, especially if x.y is a non-final release. Jim -- Jim Fulton Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: faulty releases and pypi access [update]
On Sep 26, 2007, at 6:14 PM, Jim Fulton wrote: ... I agree that the develop egg case is problematic. I'd like to think about that. Well, I thought and I thought I could probably arrange that develop eggs created by buildout got their versions from the buildout spec. Something like: [buildout] develop = . ==1.4 foo ==2.1 This would override whatever version was given in setup.py. This wouldn't help people who don't develop with buildout though. Alternatively, we could add some API that would allow our setup files to take a --version argument. So our setup files on the trunk or branches might have something like: setup( version = comman_line_version() or something. I'm not an expert on extending setuptools. I'm somewhat pessimistic about getting new features in setuptools as 0.7 seems to have fairly grandiose objectives. There don't seem to be incremental feature releases planned. :( I have a feeling that we/I should learn how to extend setuptools to get the features we need. Jim -- Jim Fulton Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: faulty releases and pypi access [update]
On Thursday 27 September 2007 07:18, Philipp von Weitershausen wrote: These are four separate cases where I've actually witnessed myself or other people mess up. We're forgetful, we can't do anything about that. We can, however, force us to catch our mistakes. I believe that if we made everybody create the tarballs from the tag, it would improve the situation a lot. Of course, an additional or other approach would be to implement a tool that checks various things. I agree that the problems you listed are solvable with doing the release from the tag, but there are cases that are not caught: 1. In your last case, if bajium would have used svn switch --relocate the file would still be around and the release would work. I imagine that most people would use svn switch because making another checkout is just a package management mess. 2. My Trove classifier problem is not solved either using this approach. Contrary to what Tres hinted on in his E-mail , if there are errors while registering with PyPI, no new release is added. Also, buildout setup . egg_info does not verify the Trove classifiers. (Note that I think the Trove classifiers are only one example of something going wrong.) 3. A serious problem occurs, if you accidentally specify the wrong package name and version in setup.py. Both happened to me yesterday, but I caught it in time. A fairly simple tool can find and report all the problems found and offer assistance. I think it is worth investing in one, especially since it will reduce my overhead since my manual checking now becomes automated. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: faulty releases and pypi access [update]
Hey, On 9/27/07, Stephan Richter [EMAIL PROTECTED] wrote: On Thursday 27 September 2007 07:18, Philipp von Weitershausen wrote: [snip] A fairly simple tool can find and report all the problems found and offer assistance. I think it is worth investing in one, especially since it will reduce my overhead since my manual checking now becomes automated. Agreed a tool could be helpful in this case as well. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: faulty releases and pypi access [update]
On 27 Sep 2007, at 13:47 , Stephan Richter wrote: On Thursday 27 September 2007 07:18, Philipp von Weitershausen wrote: These are four separate cases where I've actually witnessed myself or other people mess up. We're forgetful, we can't do anything about that. We can, however, force us to catch our mistakes. I believe that if we made everybody create the tarballs from the tag, it would improve the situation a lot. Of course, an additional or other approach would be to implement a tool that checks various things. I agree that the problems you listed are solvable with doing the release from the tag, but there are cases that are not caught: 1. In your last case, if bajium would have used svn switch -- relocate the file would still be around and the release would work. I imagine that most people would use svn switch because making another checkout is just a package management mess. Why is making another checkout a package management mess? Go to /tmp or ~/temp or whatever, get the checkout, do your release stuff and delete it again. Is this so hard? Sorry, but I fail to see how this is messy. Also, regardless of what you imagine people do, if the process says get a new, fresh checkout then this is what people should do. If they use svn switch instead, then they're not following the process. End of story. 2. My Trove classifier problem is not solved either using this approach. Contrary to what Tres hinted on in his E-mail , if there are errors while registering with PyPI, no new release is added. Also, buildout setup . egg_info does not verify the Trove classifiers. (Note that I think the Trove classifiers are only one example of something going wrong.) buildout setup? I've never seen that. I can't find any documentation on it in zc.buildout. How does it work? Does it call setup.py for every development egg in buildout.cfg? Why not just call python setup.py? Anyway, I think the Trove classifiers are an edge case. I've never seen anyone get those wrong before, to be honest. I *have* seen people get other things wrong and I think these problems would all be solved if we made it impossible to create distributions from a branch or the trunk, but made people create them from tags instead. 3. A serious problem occurs, if you accidentally specify the wrong package name and version in setup.py. Both happened to me yesterday, but I caught it in time. I assume you mean the egg name, not the package name. I'm not sure how a tool could help you here. I suppose it could use some conventions (e.g. look at the packages inside the egg) or look at the subversion URL. A fairly simple tool can find and report all the problems found and offer assistance. I think it is worth investing in one, especially since it will reduce my overhead since my manual checking now becomes automated. I'm not arguing against such a tool. If you are willing to come up with it, go for it. We should still have a proper *human* process first. A tool can then help us do the tedious bits. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: faulty releases and pypi access [update]
Philipp von Weitershausen wrote: On 27 Sep 2007, at 13:47 , Stephan Richter wrote: On Thursday 27 September 2007 07:18, Philipp von Weitershausen wrote: These are four separate cases where I've actually witnessed myself or other people mess up. We're forgetful, we can't do anything about that. We can, however, force us to catch our mistakes. I believe that if we made everybody create the tarballs from the tag, it would improve the situation a lot. Of course, an additional or other approach would be to implement a tool that checks various things. I agree that the problems you listed are solvable with doing the release from the tag, but there are cases that are not caught: 1. In your last case, if bajium would have used svn switch --relocate the file would still be around and the release would work. I imagine that most people would use svn switch because making another checkout is just a package management mess. Why is making another checkout a package management mess? Go to /tmp or ~/temp or whatever, get the checkout, do your release stuff and delete it again. Is this so hard? Sorry, but I fail to see how this is messy. Also, regardless of what you imagine people do, if the process says get a new, fresh checkout then this is what people should do. If they use svn switch instead, then they're not following the process. End of story. Release from a fresh tag check out is always good. personal I have released eggs before and after my mistake. After my mistake, I created check list for my convenience here: http://wiki.zope.org/zope3/BaijuMuthukadan An now I am making release from tag checkouts. /personal Regards, Baiju M ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: faulty releases and pypi access [update]
Jim Fulton wrote at 2007-9-26 18:14 -0400: ... We've just released 1.1. We guess the next release is 1.2. We change things and release, 1.2dev-r#. Someone fixes a bug and releases 1.1.1. Now there's a dev release of 1.2 that is actually older than the 1.1.1 release but that setuptools considers to be newer. I think this is fairly problematic. Then again, I think that dev releases are problematic in a lot of ways. In your example, it is likely, that the fix will also go into the 1.2 development branch. I.e. you will get an 1.2dev-r! with ! #. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: faulty releases and pypi access [update]
On Sep 27, 2007, at 1:42 PM, Dieter Maurer wrote: Jim Fulton wrote at 2007-9-26 18:14 -0400: ... We've just released 1.1. We guess the next release is 1.2. We change things and release, 1.2dev-r#. Someone fixes a bug and releases 1.1.1. Now there's a dev release of 1.2 that is actually older than the 1.1.1 release but that setuptools considers to be newer. I think this is fairly problematic. Then again, I think that dev releases are problematic in a lot of ways. In your example, it is likely, that the fix will also go into the 1.2 development branch. I.e. you will get an 1.2dev-r! with ! #. I'm not sure what you mean by my example or why what you said would be so. Jim -- Jim Fulton Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: faulty releases and pypi access [update]
On Wednesday 26 September 2007 10:10, Martijn Faassen wrote: This way checking CHANGES.txt should tell you what's going on with releases. If someone forgot to do the last step, you see immediately something is wrong, as you want to add your change to the 'unreleased' section but there's nothing there yet. You can then reconstruct what happened from the cheeseshop or the tags, and put in a new 'unreleased' section. Good point; of course I agree. :-) A well-maintained CHANGES.txt file is worth a lot. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: faulty releases and pypi access [update]
On Sep 26, 2007, at 10:10 AM, Martijn Faassen wrote: Stephan Richter wrote: On Wednesday 26 September 2007 05:02, Christian Theune wrote: Hmm. While doing that I also noticed that we were at 3.4.0a1 yesterday evening. The stable release was made from that without making a maintenance branch and bumping the trunk to 3.5. There is conflicting information here. :-) Some people say we need branches, others say we don't. I think it'd be good to have a tag in any case. A tag can always be converted into a branch later. Yup. I don't think there is disagreement about tags and we don't really need agreement on branches. And where is an agreed-upon document that you have to list the next version in the setup.py file after the release? Because I disagree with that, since you cannot know the next version. I disagree with too, for the same reason. What about using CHANGES.txt, which we should be maintaining anyway? I agree with a change log. CHANGES.txt is difficult to get included in distributions. Having one requires a more complex setup.py. I'd rather recommend including a change log in README.txt. Before making a release, change CHANGES.txt, and convert the section: unreleased -- Fixed bugs blah blah. To: 3.5.1 (2007-09-26) -- Fixed bugs blah blah. That is, come up with a release number, a release date, update setup.py with the release number, and tag it. Then, after the release, add in a new section: unreleased -- This way checking CHANGES.txt should tell you what's going on with releases. If someone forgot to do the last step, you see immediately something is wrong, as you want to add your change to the 'unreleased' section but there's nothing there yet. You can then reconstruct what happened from the cheeseshop or the tags, and put in a new 'unreleased' section. I agree except for the location of the change log. Jim P.S. ZODB's NEWS.txt/History.txt aren't workable for me and I plan to switch ZODB to using a change log in it's readme. Unfortunately, it's setup is so complex It will take me a largish chunk of time to unwind this. -- Jim Fulton Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: faulty releases and pypi access [update]
On Sep 26, 2007, at 10:42 AM, Stephan Richter wrote: On Wednesday 26 September 2007 10:40, Jim Fulton wrote: What about using CHANGES.txt, which we should be maintaining anyway? I agree with a change log. CHANGES.txt is difficult to get included in distributions. Having one requires a more complex setup.py. I'd rather recommend including a change log in README.txt. -1. I don't like that. We include CHANGES.txt via the long description; that's good enough for me. Do you think that the change log should be included in the distribution? Jim -- Jim Fulton Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: faulty releases and pypi access [update]
On Wednesday 26 September 2007 10:53, Jim Fulton wrote: On Sep 26, 2007, at 10:42 AM, Stephan Richter wrote: On Wednesday 26 September 2007 10:40, Jim Fulton wrote: What about using CHANGES.txt, which we should be maintaining anyway? I agree with a change log. CHANGES.txt is difficult to get included in distributions. Having one requires a more complex setup.py. I'd rather recommend including a change log in README.txt. -1. I don't like that. We include CHANGES.txt via the long description; that's good enough for me. Do you think that the change log should be included in the distribution? I am indifferent about it. I cannot see a strong argument for having it in the release. Because people read the changes before deciding to download the package. On the other hand, package managers for Linux distributions will hate us, probably. ;-) Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: faulty releases and pypi access [update]
On Wed, Sep 26, 2007 at 11:16:46AM -0400, Tres Seaver wrote: Jim Fulton wrote: On Sep 26, 2007, at 10:42 AM, Stephan Richter wrote: On Wednesday 26 September 2007 10:40, Jim Fulton wrote: What about using CHANGES.txt, which we should be maintaining anyway? I agree with a change log. CHANGES.txt is difficult to get included in distributions. Having one requires a more complex setup.py. I'd rather recommend including a change log in README.txt. -1. I don't like that. We include CHANGES.txt via the long description; that's good enough for me. Do you think that the change log should be included in the distribution? +10. The cheeseshop metadata is not where I would expect to look for a changelog; having it readable there is only helpful *before* I've downloaded. FWIW, I think that both README.txt and CHANGES.txt should be package data, so that they are discoverable after installing an egg. The top-level README.txt should be boilerplate, and point to those files (the setup.py process can then stitch them all todgether). Example from Debian: all packages have a /usr/share/doc/$packagename with the changelog and readme in there, and this is a Very Good Thing. +1 for CHANGES.txt (or NEWS.txt) in a separate file from README.txt +1 for the latest changelog entries visible on the cheeseshop page (see an announcement, go to cheeseshop, see whether you want to upgrade or not) +1 for README.txt and CHANGES.txt available to you after you install an egg. Marius Gedminas -- Despite all appearances, your boss is a thinking, feeling, human being. signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: faulty releases and pypi access [update]
On 9/26/07, Martijn Faassen [EMAIL PROTECTED] wrote: What does one need to tell setup.py to make sure CHANGES.txt is available? I understand it isn't by default, then? Hm, it does appear to be there by default. I checked grok 0.10's tgz and it's there, and we didn't do anything special. Do you mean available in the unpacked sdist, or as part of the installation? I don't think any of README, README.txt, CHANGES, CHANGES.txt (from the root of the distribution, not from inside the package) are actually installed. If they are, I'd love to know where. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Chaos is the score upon which reality is written. --Henry Miller ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: faulty releases and pypi access [update]
Hey, On 9/26/07, Fred Drake [EMAIL PROTECTED] wrote: On 9/26/07, Martijn Faassen [EMAIL PROTECTED] wrote: What does one need to tell setup.py to make sure CHANGES.txt is available? I understand it isn't by default, then? Hm, it does appear to be there by default. I checked grok 0.10's tgz and it's there, and we didn't do anything special. Do you mean available in the unpacked sdist, or as part of the installation? I don't think any of README, README.txt, CHANGES, CHANGES.txt (from the root of the distribution, not from inside the package) are actually installed. If they are, I'd love to know where. I'm just talking about the sdist. Jim gave me the impression that this was somehow difficult, but perhaps he meant something else. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: faulty releases and pypi access [update]
On Sep 26, 2007, at 1:18 PM, Fred Drake wrote: On 9/26/07, Martijn Faassen [EMAIL PROTECTED] wrote: What does one need to tell setup.py to make sure CHANGES.txt is available? I understand it isn't by default, then? Hm, it does appear to be there by default. I checked grok 0.10's tgz and it's there, and we didn't do anything special. Do you mean available in the unpacked sdist, or as part of the installation? I don't think any of README, README.txt, CHANGES, CHANGES.txt (from the root of the distribution, not from inside the package) are actually installed. If they are, I'd love to know where. By default READM(.txt) is installed in a source distribution. Anything else in the root (aside from setup.py of course and source files themselves) aren't without extra setup chants. (These chants can be figured out with some effort. I never remember them, so, if I want to do something like this, I have to figure them out again or try to find an example with them.) If we are going to have a change log, which we should, I would prefer it to be included in source distributions. Including a file other that README in the root requires extra effort that I don't want to require -- writing setup.py files is hard enough as it is. I'm not crazy about Tres' idea of putting these files in the Python packages themselves, but it does have the advantage that it causes the files to be included in eggs as well as source distributions. Jim -- Jim Fulton Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: faulty releases and pypi access [update]
Philipp von Weitershausen wrote: Stephan Richter wrote: Because I disagree with that, since you cannot know the next version. You can always know the minimum version. If you just released 3.4.2, I think it's sensible to point the next release to 3.4.3. If you later decide that you really need a feature release, you can always bump to 3.5.0a1 (which would be the first release in the 3.5.x series). Why not leave the version totally out of the setup.py in the trunk? After branching for a release we can set the version (e.g., 1.2), make a release, and tag the branch. We could either leave the version on the branch at the last release or continue the trend of mad bumping and have it at the next release (which since this is a branch, we can actually predict). I prefer the last version, but next would work too. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: faulty releases and pypi access [update]
On Sep 26, 2007, at 4:34 PM, Benji York wrote: Philipp von Weitershausen wrote: Stephan Richter wrote: Because I disagree with that, since you cannot know the next version. You can always know the minimum version. If you just released 3.4.2, I think it's sensible to point the next release to 3.4.3. If you later decide that you really need a feature release, you can always bump to 3.5.0a1 (which would be the first release in the 3.5.x series). Gary and Benji made me pay attention to this point. :) I *really* don't like setting the version to the number for the next release, since one often doesn't know what it is. Why not leave the version totally out of the setup.py in the trunk? Benji and Gary won me over to this point of view. :) After branching for a release we can set the version (e.g., 1.2), make a release, and tag the branch. We should not require branches. I would only bother creating maintenance branches when they are needed. Z, B, G, and I propose the following: - Leave the version # out of setup.py on the trunk and on branches. When it is time to make a release, either from the trunk or from a maint branch: - Update changes.txt, adding a heading for the new # and date - Create a tag - check out or switch to the tag - Set the version in setup.py on the tag. Check it in. - Make the release from the tag. (BTW, when creating maint branches after the fact, the branch should be made by copying the trunk at the revision that the first release branch for that tag was made, so as not to accidentally get a version #.) I'd prefer not to make an edict, so Benji and Gary will now persuade you that this is the best way to go. ;) Jim -- Jim Fulton Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: faulty releases and pypi access [update]
On Wednesday 26 September 2007 17:18, Jim Fulton wrote: - Update changes.txt, adding a heading for the new # and date - Create a tag - check out or switch to the tag - Set the version in setup.py on the tag. Check it in. - Make the release from the tag. Changing tags is not that good. I'd rather check in a aversion number then. ;-) Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: faulty releases and pypi access [update]
On Sep 26, 2007, at 5:28 PM, Stephan Richter wrote: On Wednesday 26 September 2007 17:18, Jim Fulton wrote: - Update changes.txt, adding a heading for the new # and date - Create a tag - check out or switch to the tag - Set the version in setup.py on the tag. Check it in. - Make the release from the tag. Changing tags is not that good. I'd rather check in a aversion number then. ;-) This is exactly what we've been doing for Zope 3 releases -- for the same reason. I think it is the one acceptable and reasonable change to a tag. The benefit of forcing us to release from a tag is, imo, significant. Jim -- Jim Fulton Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: faulty releases and pypi access [update]
On 26 Sep 2007, at 23:18 , Jim Fulton wrote: On Sep 26, 2007, at 4:34 PM, Benji York wrote: Philipp von Weitershausen wrote: Stephan Richter wrote: Because I disagree with that, since you cannot know the next version. You can always know the minimum version. If you just released 3.4.2, I think it's sensible to point the next release to 3.4.3. If you later decide that you really need a feature release, you can always bump to 3.5.0a1 (which would be the first release in the 3.5.x series). Gary and Benji made me pay attention to this point. :) I *really* don't like setting the version to the number for the next release, since one often doesn't know what it is. Maybe. However, when you do the actual release then, you're still going to have to find out which version number to use. On release branches this is a trivial step, of course: You just look at the latest tagged version and increment accordingly. On the trunk it might be trickier. After 1.0, do we have 1.1? Or 2.0? Maye this aspect isn't such a big deal, though. Why not leave the version totally out of the setup.py in the trunk? Benji and Gary won me over to this point of view. :) There's a *really* good reason for putting the upcoming version number in setup.py, though: development eggs. Let's say X depends on Y and I'm developing them simultaneously as development eggs in one sandbox (e.g. buildout). I add a feature to Y that I'd like to use in X. That means I'll have to change X's version dependency regarding Y so that it now depends on Ya.b where a.b is the latest release that didn't have the feature I added. Will Y with the setup.py stating version='unreleased' satisfy the Ya.b requirement that X (rightfully) has? If not, then I think we have a problem. If yes, then I find that very confusing. I know that if Y's setup.py stated version='a.b-dev', it will work. This what my guide currently suggests (including taking it out just for release tags). After branching for a release we can set the version (e.g., 1.2), make a release, and tag the branch. We should not require branches. I would only bother creating maintenance branches when they are needed. +1 Z, B, G, and I propose the following: Who's Z? :) - Leave the version # out of setup.py on the trunk and on branches. When it is time to make a release, either from the trunk or from a maint branch: - Update changes.txt, adding a heading for the new # and date - Create a tag - check out or switch to the tag - Set the version in setup.py on the tag. Check it in. - Make the release from the tag. I could live with that, even with the fact that you'd be modifying a tag, as long as it's done in this exact order and the only modificdations to a tag woudl be setting setup.py. I still see the development egg case the best argument for putting the next anticipated version number into setup.py. I think the compromise of version number + 'dev' marker would work best. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: faulty releases and pypi access [update]
On Wednesday 26 September 2007 17:34, Jim Fulton wrote: On Sep 26, 2007, at 5:28 PM, Stephan Richter wrote: On Wednesday 26 September 2007 17:18, Jim Fulton wrote: - Update changes.txt, adding a heading for the new # and date - Create a tag - check out or switch to the tag - Set the version in setup.py on the tag. Check it in. - Make the release from the tag. Changing tags is not that good. I'd rather check in a aversion number then. ;-) This is exactly what we've been doing for Zope 3 releases -- for the same reason. I think it is the one acceptable and reasonable change to a tag. The benefit of forcing us to release from a tag is, imo, significant. Here is a problem that I discussed with Marius earlier today. I often do not know whether all my setup.py settings are correct until I try to upload a release. I frequently get the Development Status classifier wrong and I won't be told it is wrong until I try to register the release. So I usually create the release first and upload it and after that create the tag. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: faulty releases and pypi access [update]
On 26 Sep 2007, at 22:34 , Benji York wrote: Philipp von Weitershausen wrote: Stephan Richter wrote: Because I disagree with that, since you cannot know the next version. You can always know the minimum version. If you just released 3.4.2, I think it's sensible to point the next release to 3.4.3. If you later decide that you really need a feature release, you can always bump to 3.5.0a1 (which would be the first release in the 3.5.x series). Why not leave the version totally out of the setup.py in the trunk? After branching for a release we can set the version (e.g., 1.2), make a release, and tag the branch. We could either leave the version on the branch at the last release or continue the trend of mad bumping and have it at the next release (which since this is a branch, we can actually predict). I prefer the last version, but next would work too. setuptools suggests setting it to the next version. Apart from the fact that it makes more sense to me, the biggest reason I can see is the development egg use case. A development egg from the repository should have a newer version than the latest released egg. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: faulty releases and pypi access [update]
On 26 Sep 2007, at 23:41 , Stephan Richter wrote: On Wednesday 26 September 2007 17:34, Jim Fulton wrote: On Sep 26, 2007, at 5:28 PM, Stephan Richter wrote: On Wednesday 26 September 2007 17:18, Jim Fulton wrote: - Update changes.txt, adding a heading for the new # and date - Create a tag - check out or switch to the tag - Set the version in setup.py on the tag. Check it in. - Make the release from the tag. Changing tags is not that good. I'd rather check in a aversion number then. ;-) This is exactly what we've been doing for Zope 3 releases -- for the same reason. I think it is the one acceptable and reasonable change to a tag. The benefit of forcing us to release from a tag is, imo, significant. Here is a problem that I discussed with Marius earlier today. I often do not know whether all my setup.py settings are correct until I try to upload a release. I frequently get the Development Status classifier wrong and I won't be told it is wrong until I try to register the release. A good way to catch errors before you mess with the CheeseShop is to create the egg info and look at it: $ python setup.py egg_info $ less src/EGG.egg-info/PKG-INFO So I usually create the release first and upload it and after that create the tag. Well, you could just as well re-tag when you screwed up. Or just fix minor things on the tag and merge them back to the branch. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: faulty releases and pypi access [update]
On Sep 26, 2007, at 5:37 PM, Philipp von Weitershausen wrote: On 26 Sep 2007, at 23:18 , Jim Fulton wrote: On Sep 26, 2007, at 4:34 PM, Benji York wrote: Philipp von Weitershausen wrote: Stephan Richter wrote: Because I disagree with that, since you cannot know the next version. You can always know the minimum version. If you just released 3.4.2, I think it's sensible to point the next release to 3.4.3. If you later decide that you really need a feature release, you can always bump to 3.5.0a1 (which would be the first release in the 3.5.x series). Gary and Benji made me pay attention to this point. :) I *really* don't like setting the version to the number for the next release, since one often doesn't know what it is. Maybe. However, when you do the actual release then, you're still going to have to find out which version number to use. On release branches this is a trivial step, of course: You just look at the latest tagged version and increment accordingly. On the trunk it might be trickier. After 1.0, do we have 1.1? Or 2.0? Maye this aspect isn't such a big deal, though. You can always look at the previous tags or at CHANGES.txt. Why not leave the version totally out of the setup.py in the trunk? Benji and Gary won me over to this point of view. :) There's a *really* good reason for putting the upcoming version number in setup.py, though: development eggs. Good point. Let's say X depends on Y and I'm developing them simultaneously as development eggs in one sandbox (e.g. buildout). I add a feature to Y that I'd like to use in X. That means I'll have to change X's version dependency regarding Y so that it now depends on Ya.b where a.b is the latest release that didn't have the feature I added. Will Y with the setup.py stating version='unreleased' satisfy the Ya.b requirement that X (rightfully) has? If not, then I think we have a problem. If yes, then I find that very confusing. Leaving aside for the moment the fact that develop eggs are used for system egg installs :(, I think if a buildout uses a develop egg, there should be a very strong presumption that it it should be used. OTOH, if you have a part that depends on a previous major version, then you don't really want to use a develop egg for the later release. This is a bit of an edge case though. I know that if Y's setup.py stated version='a.b-dev', it will work. This what my guide currently suggests (including taking it out just for release tags). A problem with this is that someone else might make a release of Y, either to fix a bug or to add a feature while your working on the new feature in Y. After branching for a release we can set the version (e.g., 1.2), make a release, and tag the branch. We should not require branches. I would only bother creating maintenance branches when they are needed. +1 Z, B, G, and I propose the following: Who's Z? :) - Leave the version # out of setup.py on the trunk and on branches. When it is time to make a release, either from the trunk or from a maint branch: - Update changes.txt, adding a heading for the new # and date - Create a tag - check out or switch to the tag - Set the version in setup.py on the tag. Check it in. - Make the release from the tag. I could live with that, even with the fact that you'd be modifying a tag, as long as it's done in this exact order and the only modificdations to a tag woudl be setting setup.py. I still see the development egg case the best argument for putting the next anticipated version number into setup.py. I think the compromise of version number + 'dev' marker would work best. I agree that the develop egg case is problematic. I'd like to think about that. If you ever actually make dev releases, then guessing wrong about the next version could cause real problems. Consider the following case: We've just released 1.1. We guess the next release is 1.2. We change things and release, 1.2dev-r#. Someone fixes a bug and releases 1.1.1. Now there's a dev release of 1.2 that is actually older than the 1.1.1 release but that setuptools considers to be newer. I think this is fairly problematic. Then again, I think that dev releases are problematic in a lot of ways. Jim -- Jim Fulton Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: faulty releases and pypi access [update]
On 27 Sep 2007, at 00:14 , Jim Fulton wrote: Let's say X depends on Y and I'm developing them simultaneously as development eggs in one sandbox (e.g. buildout). I add a feature to Y that I'd like to use in X. That means I'll have to change X's version dependency regarding Y so that it now depends on Ya.b where a.b is the latest release that didn't have the feature I added. Will Y with the setup.py stating version='unreleased' satisfy the Ya.b requirement that X (rightfully) has? If not, then I think we have a problem. If yes, then I find that very confusing. Leaving aside for the moment the fact that develop eggs are used for system egg installs :(, I think if a buildout uses a develop egg, there should be a very strong presumption that it it should be used. OTOH, if you have a part that depends on a previous major version, then you don't really want to use a develop egg for the later release. This is a bit of an edge case though. It is as long as you ignore the fact that all major Linux distros install develop eggs into site-packages. I still see the development egg case the best argument for putting the next anticipated version number into setup.py. I think the compromise of version number + 'dev' marker would work best. I agree that the develop egg case is problematic. I'd like to think about that. If you ever actually make dev releases, then guessing wrong about the next version could cause real problems. Oh, I'm not actually thinking about dev releases. I too think they're very problematic. I just suggested using the 'dev' marker as a way to tell branches or the trunk apart from tags. On the branches and trunk, setup.py's version is the next anticipated release + 'dev', while on tags it's just release version. That way people won't accidentally make releases from branches or the trunk (because they'd get an egg with a 'dev' in the version). They'll have to use a tag. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: faulty releases and pypi access [update]
On Sep 26, 2007, at 6:23 PM, Philipp von Weitershausen wrote: On 27 Sep 2007, at 00:14 , Jim Fulton wrote: Let's say X depends on Y and I'm developing them simultaneously as development eggs in one sandbox (e.g. buildout). I add a feature to Y that I'd like to use in X. That means I'll have to change X's version dependency regarding Y so that it now depends on Ya.b where a.b is the latest release that didn't have the feature I added. Will Y with the setup.py stating version='unreleased' satisfy the Ya.b requirement that X (rightfully) has? If not, then I think we have a problem. If yes, then I find that very confusing. Leaving aside for the moment the fact that develop eggs are used for system egg installs :(, I think if a buildout uses a develop egg, there should be a very strong presumption that it it should be used. OTOH, if you have a part that depends on a previous major version, then you don't really want to use a develop egg for the later release. This is a bit of an edge case though. It is as long as you ignore the fact that all major Linux distros install develop eggs into site-packages. I already left that aside. :) Buildout should be able to detect this case and deal with it, which is why I left it aside. I still see the development egg case the best argument for putting the next anticipated version number into setup.py. I think the compromise of version number + 'dev' marker would work best. I agree that the develop egg case is problematic. I'd like to think about that. If you ever actually make dev releases, then guessing wrong about the next version could cause real problems. Oh, I'm not actually thinking about dev releases. I too think they're very problematic. I just suggested using the 'dev' marker as a way to tell branches or the trunk apart from tags. But people will make these releases and leaving the version out will mean that these releases will be harmless. On the branches and trunk, setup.py's version is the next anticipated release + 'dev', while on tags it's just release version. That way people won't accidentally make releases from branches or the trunk (because they'd get an egg with a 'dev' in the version). They'll have to use a tag. You think getting an egg with dev in the version will stop them? Jim -- Jim Fulton Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com