Re: [Zope-dev] [Checkins] SVN: zope.app.security/trunk/ keep trunk version at 0. Update changes
Martijn Faassen, on 2009-09-11: (I think zest.releaser also does the version bumping before tagging if I'm not mistaken, even with SVN.) Correct. These are the svn logs of releasing a demo package: $ svn log -v file:///home/maurits/tmp/repo/demo/ r5 | maurits | 2009-09-14 14:39:50 +0200 (ma, 14 sep 2009) | 1 line Changed paths: M /demo/trunk/CHANGES.txt M /demo/trunk/setup.py Preparing release 0.1 r6 | maurits | 2009-09-14 14:39:55 +0200 (ma, 14 sep 2009) | 1 line Changed paths: A /demo/tags/0.1 (from /demo/trunk:5) Tagging 0.1 r7 | maurits | 2009-09-14 14:40:00 +0200 (ma, 14 sep 2009) | 1 line Changed paths: M /demo/trunk/CHANGES.txt M /demo/trunk/setup.py Back to development: 0.2dev -- Maurits van Rees | http://maurits.vanrees.org/ Work | http://zestsoftware.nl/ This is your day, don't let them take it away. [Barlow Girl] ___ 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] [Checkins] SVN: zope.app.security/trunk/ keep trunk version at 0. Update changes
On 2009-9-10 23:24, Benji York wrote: On Thu, Sep 10, 2009 at 5:20 PM, Wichert Akkermanwich...@wiggy.net wrote: On 2009-9-10 22:23, Benji York wrote: 2) if you accidentally make a trunk release no one will accedentally use it because it will be the oldest release on PyPI instead of the newest, Doesn't it break all versioned dependencies on that package? I don't understand the question, so I'll say no. ;) Suppose you are working on an app which includes a package that depends on A = 2.1 to make sure it can use a new API introduced in A 2.1. If you then add a develop egg for A to do some work on it things break with this policy because it will have version 0 and can no longer satisfy the = 2.1 requirement. Wichert. -- Wichert Akkerman wich...@wiggy.net It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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] [Checkins] SVN: zope.app.security/trunk/ keep trunk version at 0. Update changes
On Fri, Sep 11, 2009 at 2:20 AM, Wichert Akkerman wich...@wiggy.net wrote: Suppose you are working on an app which includes a package that depends on A = 2.1 to make sure it can use a new API introduced in A 2.1. If you then add a develop egg for A to do some work on it things break with this policy because it will have version 0 and can no longer satisfy the = 2.1 requirement. Gotcha. Yep that's a down side of the zero approach. For me the scale still tips to using zero as the trunk version. -- Benji York Senior Software Engineer Zope Corporation ___ 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] [Checkins] SVN: zope.app.security/trunk/ keep trunk version at 0. Update changes
Benji York wrote: On Fri, Sep 11, 2009 at 2:20 AM, Wichert Akkerman wich...@wiggy.net wrote: Suppose you are working on an app which includes a package that depends on A = 2.1 to make sure it can use a new API introduced in A 2.1. If you then add a develop egg for A to do some work on it things break with this policy because it will have version 0 and can no longer satisfy the = 2.1 requirement. Gotcha. Yep that's a down side of the zero approach. For me the scale still tips to using zero as the trunk version. Well, the official policy of the ZTK is still to use the 'dev' approach. We can't just suddenly start to use something else just like that, without discussion. So, could you please follow this policy for ZTK packages in SVN? In addition, if you are going to release to pypi, there are tools like zest.releaser which make doing a release in the official way a snap (version-bump and all). Regards, Martijn ___ 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] [Checkins] SVN: zope.app.security/trunk/ keep trunk version at 0. Update changes
On Thu, Sep 10, 2009 at 04:23:31PM -0400, Benji York wrote: On Thu, Sep 10, 2009 at 4:12 PM, Hanno Schlichting ha...@hannosch.eu wrote: On Thu, Sep 10, 2009 at 9:46 PM, Alex Chapmanachap...@zope.com wrote: Log message for revision 103721: keep trunk version at 0. Update changes I think I've seen the practice of denoting the version on trunk as zero from Jim already. It is in conflict with http://docs.zope.org/zopetoolkit/process/releasing-software.html though. The majority of packages still uses the version='3.4.2dev' scheme for trunk or branches. Pointing to the next release to be made with a dev marker. Are there any particular reasons, why this policy should be changed? I like 0 for two reasons: 1) it doesn't require predicting what the next release will be, This is why I'd be happier if setuptools supported/sanctioned the convention sometimes used in Debian: after releasing version 1.2.3 change it in trunk to 1.2.3+svn. It has the downside that you're explicitly naming the version control system you happen to use, but *shrug*, it doesn't have to always be svn. Call it the 1.2.3+$vcs convention. Currently I always assume the next release may be a tiny bugfix release, so 1.2.3 becomes 1.2.4dev. If I commit something that adds a feature or breaks an API, I can change it to 1.3dev or 2.0dev. I like that it gives me a reminder of the scope of the changes made since the last release, but, since I'm not disciplined enough to always update the version number and changelog along with a page, I prefer reviewing the full diff before releasing to make sure they're up to date. 3) [no] superfluous version bumps on the trunk I don't understand this one. Could you elaborate? Amongst the reasons I like it are that: - when using a checkout as a develop egg you don't have to worry about finding out the exact version used on the trunk, you can always just use 0. That's nice. I think I tried to use [versions] my-dev-package = to force the regular use latest logic, but IIRC it didn't work well. Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development signature.asc Description: Digital 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] [Checkins] SVN: zope.app.security/trunk/ keep trunk version at 0. Update changes
On Fri, Sep 11, 2009 at 8:53 AM, Martijn Faassen faas...@startifact.com wrote: So, could you please follow this policy for ZTK packages in SVN? I suspect it would help if packages that are part of the ZTK have that indicated somewhere convenient, like near where the version number is specified in the setup.py file. Possibly with a link to the ZTK release policies. When making changes, we're often considering the relevant packages in isolation or in the context of our own applications, so a pointer to additional policies that apply is helpful. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Chaos is the score upon which reality is written. --Henry Miller ___ 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] [Checkins] SVN: zope.app.security/trunk/ keep trunk version at 0. Update changes
On Fri, Sep 11, 2009 at 9:07 AM, Marius Gedminas mar...@gedmin.as wrote: On Thu, Sep 10, 2009 at 04:23:31PM -0400, Benji York wrote: 3) [no] superfluous version bumps on the trunk I don't understand this one. Could you elaborate? The current practice is that after doing a release you have to change the trunk version to the next release number (a version bump). - when using a checkout as a develop egg you don't have to worry about finding out the exact version used on the trunk, you can always just use 0. That's nice. I think I tried to use [versions] my-dev-package = Yeah, it'd be nice if buildout allowed that or some other syntax (like my-dev-package = *). -- Benji York Senior Software Engineer Zope Corporation ___ 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] [Checkins] SVN: zope.app.security/trunk/ keep trunk version at 0. Update changes
On Fri, Sep 11, 2009 at 8:53 AM, Martijn Faassen faas...@startifact.com wrote: Well, the official policy of the ZTK is still to use the 'dev' approach. We can't just suddenly start to use something else just like that, without discussion. Absolutely. This is that discussion. :) In addition, if you are going to release to pypi, there are tools like zest.releaser which make doing a release in the official way a snap (version-bump and all). That's good to know. -- Benji York Senior Software Engineer Zope Corporation ___ 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] [Checkins] SVN: zope.app.security/trunk/ keep trunk version at 0. Update changes
On Sep 11, 2009, at 9:53 AM, Benji York wrote: On Fri, Sep 11, 2009 at 9:07 AM, Marius Gedminas mar...@gedmin.as wrote: On Thu, Sep 10, 2009 at 04:23:31PM -0400, Benji York wrote: 3) [no] superfluous version bumps on the trunk I don't understand this one. Could you elaborate? The current practice is that after doing a release you have to change the trunk version to the next release number (a version bump). - when using a checkout as a develop egg you don't have to worry about finding out the exact version used on the trunk, you can always just use 0. That's nice. I think I tried to use [versions] my-dev-package = Yeah, it'd be nice if buildout allowed that or some other syntax (like my-dev-package = *). ...Mmm, what Marius describes works for me, I believe. I've definitely used that trick and showed it to others, at least. Maybe it worked by mistake? /me wonders if he was doing something wrong, or if he remembersbut doesn't take the time to try it again right now. But to the bigger discussion here, I'm in the I don't like 0 camp, as I've said before. I like seeing the version number when I look at the trunk, which I do when I am doing different things than when I look at PyPI. I am skeptical of an argument that it helps prevent accidental releases. Is it not possible to make a '0' release? If it is possible, then you have to be just as careful. I think contemplating automation (e.g., release helpers that help you do the right thing, and warn you if it looks like you are doing a wrong one) is a better avenue in any case. Certainly the automation of setup.py sdist register upload is a thing of beauty in my eyes, and it could be improved. zest.releaser might be good, dunno. Also, since I'm also in the setup.py should be able to specify minimum versions camp (admittedly unlike others, such as Benji, to my continued surprise), I have another issue. When you use externals/ develop-eggs to organize your dependencies during interlocked jobs like my recent efforts with zc.buildout/zc.recipe.testing/ z3c.recipe.filetemplate, and you want to set a minimum dependency for one or more of the develop-eggs, this breaks if your external has a version number of 0. The '0' pattern seems like a loss for me, and at best a minimal win for those that are arguing for it. I'd prefer not to see a change, with the usual associated costs of communication and check-in police. That said, I don't this is worth a big argument, or even a big discussion (or even this email? :-). If the Zope triumverate or whatever it is these days changes the release document, so be it. :-) Gary ___ 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] [Checkins] SVN: zope.app.security/trunk/ keep trunk version at 0. Update changes
On Fri, Sep 11, 2009 at 10:30 AM, Gary Poster gary.pos...@gmail.com wrote: Also, since I'm also in the setup.py should be able to specify minimum versions camp (admittedly unlike others, such as Benji, to my continued surprise) I've gotta keep you guessing somehow. ;) The '0' pattern seems like a loss for me, and at best a minimal win for those that are arguing for it. I'd prefer not to see a change, with the usual associated costs of communication and check-in police. Given the way the ZTK policies have shaped up I think I have to agree that zero on the trunk will probably be a small loss for most people working on ZTK projects. For the way I develop non-ZTK software the zeros are a small win. Luckily most of the software I develop isn't in the ZTK, so I'm fine with the status quo. -- Benji York Senior Software Engineer Zope Corporation ___ 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] [Checkins] SVN: zope.app.security/trunk/ keep trunk version at 0. Update changes
On Fri, Sep 11, 2009 at 10:41 AM, Martijn Faassen faas...@startifact.com wrote: Benji York wrote: On Fri, Sep 11, 2009 at 8:53 AM, Martijn Faassen faas...@startifact.com wrote: Well, the official policy of the ZTK is still to use the 'dev' approach. We can't just suddenly start to use something else just like that, without discussion. Absolutely. This is that discussion. :) It's good we're having it now, but I'd much prefer to have one in advance. Alex's change was a simple mistake. He works with packages that use both styles. There wasn't any subversive intent. -- Benji York Senior Software Engineer Zope Corporation ___ 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] [Checkins] SVN: zope.app.security/trunk/ keep trunk version at 0. Update changes
Gary Poster wrote: [snip] ...Mmm, what Marius describes works for me, I believe. I've definitely used that trick and showed it to others, at least. Maybe it worked by mistake? /me wonders if he was doing something wrong, or if he remembersbut doesn't take the time to try it again right now. I'd worked for me too, but perhaps it just works by random chance. :) zest.releaser might be good, dunno. I was skeptical of using release helpers, but then I used zest.releaser and I haven't looked back. A friend of mine had the same experience. Also, since I'm also in the setup.py should be able to specify minimum versions camp (admittedly unlike others, such as Benji, to my continued surprise), Doing this is official ZTK policy, actually. (though bugfix versions are too fine-grained to require in this policy) [snip] That said, I don't this is worth a big argument, or even a big discussion (or even this email? :-). If the Zope triumverate or whatever it is these days changes the release document, so be it. :-) It didn't think our release policy was worth any argument - I thought we had people on board with it by now. But apparently I was wrong. Regards, Martijn ___ 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] [Checkins] SVN: zope.app.security/trunk/ keep trunk version at 0. Update changes
On Fri, Sep 11, 2009 at 10:30 AM, Gary Poster gary.pos...@gmail.com wrote: Also, since I'm also in the setup.py should be able to specify minimum versions camp (admittedly unlike others, such as Benji, to my continued surprise) I agree with you on this point; it's quite useful for setup.py to be able to specify such requirement constraints. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Chaos is the score upon which reality is written. --Henry Miller ___ 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] [Checkins] SVN: zope.app.security/trunk/ keep trunk version at 0. Update changes
Fred Drake wrote: On Fri, Sep 11, 2009 at 8:53 AM, Martijn Faassen faas...@startifact.com wrote: So, could you please follow this policy for ZTK packages in SVN? I suspect it would help if packages that are part of the ZTK have that indicated somewhere convenient, like near where the version number is specified in the setup.py file. Possibly with a link to the ZTK release policies. When making changes, we're often considering the relevant packages in isolation or in the context of our own applications, so a pointer to additional policies that apply is helpful. That's a good idea. The extreme version of this reminder would to mark it in a lot of places in the package - in every python file and in setup.py near the version and near the dependencies listing and every aspect that could possibly be affected by ZTK policy. That is unworkable. I figured a reference to the ZTK policies on the top of the setup.py would be enough to remind people. I've just committed these changes. I've also taken the liberty to update the ZTK policy to say that this should be done. (other steering group members can call me back if they don't like this policy change :) Regards, Martijn ___ 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] [Checkins] SVN: zope.app.security/trunk/ keep trunk version at 0. Update changes
On Fri, Sep 11, 2009 at 09:53:51AM -0400, Benji York wrote: On Fri, Sep 11, 2009 at 9:07 AM, Marius Gedminas mar...@gedmin.as wrote: On Thu, Sep 10, 2009 at 04:23:31PM -0400, Benji York wrote: 3) [no] superfluous version bumps on the trunk I don't understand this one. Could you elaborate? The current practice is that after doing a release you have to change the trunk version to the next release number (a version bump). Right, but where does the superfluous come from? You'd have to change it to 0 anywa... Ah, I just realized that you do the version change on the branch/tag, so trunk always stays at version 0. (I don't do that out of principle that tags ought not to be modified; and besides in other VCSes they can't be.) - when using a checkout as a develop egg you don't have to worry about finding out the exact version used on the trunk, you can always just use 0. That's nice. I think I tried to use [versions] my-dev-package = Yeah, it'd be nice if buildout allowed that or some other syntax (like my-dev-package = *). Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development signature.asc Description: Digital 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] [Checkins] SVN: zope.app.security/trunk/ keep trunk version at 0. Update changes
Hey, Marius Gedminas wrote: On Fri, Sep 11, 2009 at 09:53:51AM -0400, Benji York wrote: On Fri, Sep 11, 2009 at 9:07 AM, Marius Gedminas mar...@gedmin.as wrote: On Thu, Sep 10, 2009 at 04:23:31PM -0400, Benji York wrote: 3) [no] superfluous version bumps on the trunk I don't understand this one. Could you elaborate? The current practice is that after doing a release you have to change the trunk version to the next release number (a version bump). Right, but where does the superfluous come from? You'd have to change it to 0 anywa... Ah, I just realized that you do the version change on the branch/tag, so trunk always stays at version 0. (I don't do that out of principle that tags ought not to be modified; and besides in other VCSes they can't be.) That's an interesting point. So if we were to adopt another version control system, the 0 policy wouldn't be much of a win anymore. Perhaps Gary can tell us whether this would work with bzr? (I think zest.releaser also does the version bumping before tagging if I'm not mistaken, even with SVN.) Regards, Martijn ___ 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] [Checkins] SVN: zope.app.security/trunk/ keep trunk version at 0. Update changes
On Sep 11, 2009, at 12:05 PM, Martijn Faassen wrote: Hey, Marius Gedminas wrote: On Fri, Sep 11, 2009 at 09:53:51AM -0400, Benji York wrote: On Fri, Sep 11, 2009 at 9:07 AM, Marius Gedminas mar...@gedmin.as wrote: On Thu, Sep 10, 2009 at 04:23:31PM -0400, Benji York wrote: 3) [no] superfluous version bumps on the trunk I don't understand this one. Could you elaborate? The current practice is that after doing a release you have to change the trunk version to the next release number (a version bump). Right, but where does the superfluous come from? You'd have to change it to 0 anywa... Ah, I just realized that you do the version change on the branch/ tag, so trunk always stays at version 0. (I don't do that out of principle that tags ought not to be modified; and besides in other VCSes they can't be.) That's an interesting point. So if we were to adopt another version control system, the 0 policy wouldn't be much of a win anymore. Perhaps Gary can tell us whether this would work with bzr? bzr supports a classic definition of tags--identifying a specific revision. If it's of interest or help, I include the help text for the tag command at the end of my message. (The way we accomplish tagging in svn is by bringing our own semantics to certain names, of course. svn doesn't help us do that inherently, it's just convention. Because that's essentially a feature of being able to name stuff, you can do similar tricks with bzr--I'd make a branch for a tag if we were were following that pattern.) Gary $ bzr help tag Purpose: Create, remove or modify a tag naming a revision. Usage: bzr tag TAG_NAME Options: --force Replace existing tags. -v, --verbose Display more information. -h, --helpShow help message. -q, --quiet Only display errors and warnings. -d ARG, --directory=ARG Branch in which to place the tag. --usage Show usage message and options. -r ARG, --revision=ARG See help revisionspec for details. --delete Delete this tag rather than placing it. Description: Tags give human-meaningful names to revisions. Commands that take a -r (--revision) option can be given -rtag:X, where X is any previously created tag. Tags are stored in the branch. Tags are copied from one branch to another along when you branch, push, pull or merge. It is an error to give a tag name that already exists unless you pass --force, in which case the tag is moved to point to the new revision. To rename a tag (change the name but keep it on the same revsion), run ``bzr tag new-name -r tag:old-name`` and then ``bzr tag --delete oldname``. ___ 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] [Checkins] SVN: zope.app.security/trunk/ keep trunk version at 0. Update changes
On Thu, Sep 10, 2009 at 9:46 PM, Alex Chapmanachap...@zope.com wrote: Log message for revision 103721: keep trunk version at 0. Update changes I think I've seen the practice of denoting the version on trunk as zero from Jim already. It is in conflict with http://docs.zope.org/zopetoolkit/process/releasing-software.html though. The majority of packages still uses the version='3.4.2dev' scheme for trunk or branches. Pointing to the next release to be made with a dev marker. Are there any particular reasons, why this policy should be changed? Hanno ___ 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] [Checkins] SVN: zope.app.security/trunk/ keep trunk version at 0. Update changes
On Thu, Sep 10, 2009 at 4:12 PM, Hanno Schlichting ha...@hannosch.eu wrote: On Thu, Sep 10, 2009 at 9:46 PM, Alex Chapmanachap...@zope.com wrote: Log message for revision 103721: keep trunk version at 0. Update changes I think I've seen the practice of denoting the version on trunk as zero from Jim already. It is in conflict with http://docs.zope.org/zopetoolkit/process/releasing-software.html though. The majority of packages still uses the version='3.4.2dev' scheme for trunk or branches. Pointing to the next release to be made with a dev marker. Are there any particular reasons, why this policy should be changed? I like 0 for two reasons: 1) it doesn't require predicting what the next release will be, 2) if you accidentally make a trunk release no one will accedentally use it because it will be the oldest release on PyPI instead of the newest, Three, I like it for three reasons: 3) so superfluous version bumps on the trunk Amongst the reasons I like it are that: - when using a checkout as a develop egg you don't have to worry about finding out the exact version used on the trunk, you can always just use 0. -- Benji York Senior Software Engineer Zope Corporation ___ 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] [Checkins] SVN: zope.app.security/trunk/ keep trunk version at 0. Update changes
On 2009-9-10 22:23, Benji York wrote: On Thu, Sep 10, 2009 at 4:12 PM, Hanno Schlichtingha...@hannosch.eu wrote: On Thu, Sep 10, 2009 at 9:46 PM, Alex Chapmanachap...@zope.com wrote: Log message for revision 103721: keep trunk version at 0. Update changes I think I've seen the practice of denoting the version on trunk as zero from Jim already. It is in conflict with http://docs.zope.org/zopetoolkit/process/releasing-software.html though. The majority of packages still uses the version='3.4.2dev' scheme for trunk or branches. Pointing to the next release to be made with a dev marker. Are there any particular reasons, why this policy should be changed? I like 0 for two reasons: 1) it doesn't require predicting what the next release will be, 2) if you accidentally make a trunk release no one will accedentally use it because it will be the oldest release on PyPI instead of the newest, Doesn't it break all versioned dependencies on that package? Wichert. -- Wichert Akkerman wich...@wiggy.net It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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] [Checkins] SVN: zope.app.security/trunk/ keep trunk version at 0. Update changes
On Thu, Sep 10, 2009 at 5:20 PM, Wichert Akkerman wich...@wiggy.net wrote: On 2009-9-10 22:23, Benji York wrote: 2) if you accidentally make a trunk release no one will accedentally use it because it will be the oldest release on PyPI instead of the newest, Doesn't it break all versioned dependencies on that package? I don't understand the question, so I'll say no. ;) -- Benji York Senior Software Engineer Zope Corporation ___ 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 )
