official release policy ZTK is still not changed
Hi there, Apparently some people are using '0' instead of the next version for packages in the ZTK. Please do not do this for ZTK packages. The official policy for releasing is here. http://docs.zope.org/zopetoolkit/process/releasing-software.html It is also all right to use a tool like zest.releaser, which automates this for you (I do believe there's a slight deviation of the policy at some point, but the end results are the same). Regards, Martijn
On Fri, Sep 11, 2009 at 8:55 AM, Martijn Faassen <faassen@startifact.com> wrote:
Hi there,
Apparently some people are using '0' instead of the next version for packages in the ZTK.
Please do not do this for ZTK packages. The official policy for releasing is here.
http://docs.zope.org/zopetoolkit/process/releasing-software.html
I don't understand why this would be important, but if it is, I propose to using 0 instead of the dev of the next version. Where I've used '0', I've found it to be less error prone. Ir also requires less effort because it means you never have to edit the version on the trunk. Jim -- Jim Fulton
Hey, Jim Fulton wrote:
On Fri, Sep 11, 2009 at 8:55 AM, Martijn Faassen <faassen@startifact.com> wrote:
Hi there,
Apparently some people are using '0' instead of the next version for packages in the ZTK.
Please do not do this for ZTK packages. The official policy for releasing is here.
http://docs.zope.org/zopetoolkit/process/releasing-software.html
I don't understand why this would be important,
?!.. See my comment below.
but if it is, I propose to using 0 instead of the dev of the next version. Where I've used '0', I've found it to be less error prone. Ir also requires less effort because it means you never have to edit the version on the trunk.
I'm -1 to using 0. Reasons: * it breaks dependencies on development versions which have version requirements in it (see Wichert's comments on the original thread). We're supposed to be maintaining these: see the version requirements in setup.py decision of the steering group: http://docs.zope.org/zopetoolkit/steeringgroup/decisions.html * I (and others) use tools to do releases (zest.releaser in my case). These tools are based on this policy. Changing the policy breaks the tools. * change with little gain (and some loss) to a policy which we've had for years and works fine. (Philipp wrote this sometime in 2007 or so, and we were already having debates about doing VBs back then. Christian added it in the documentation that turned into the ZTK documentation right away) I'm also particularly disgruntled that people just started deviating from the ZTK policy without discussion. Goes completely against the point of having a steering group and a written down policy. Comments like "I don't understand why this should be important" don't improve my mood. The whole point of writing down policy is so everybody knows what it is and will use it, instead of it being some randomly evolving community practice. This way it is much easier to help new people get up to speed in our community, maintain consistent practices, and people already in our community will also have an easier time keeping track of what's going on. [I hope people who appreciate having such a policy will chip in here and say "yes, I want a written-down policy, please" so it isn't just me who is telling Jim this.] Regards, Martijn
On Fri, Sep 11, 2009 at 10:11 AM, Martijn Faassen <faassen@startifact.com> wrote:
Hey,
Jim Fulton wrote:
On Fri, Sep 11, 2009 at 8:55 AM, Martijn Faassen <faassen@startifact.com> wrote:
Hi there,
Apparently some people are using '0' instead of the next version for packages in the ZTK.
Please do not do this for ZTK packages. The official policy for releasing is here.
http://docs.zope.org/zopetoolkit/process/releasing-software.html
I don't understand why this would be important,
?!..
See my comment below.
but if it is, I propose to using 0 instead of the dev of the next version. Where I've used '0', I've found it to be less error prone. Ir also requires less effort because it means you never have to edit the version on the trunk.
I'm -1 to using 0.
Reasons:
* it breaks dependencies on development versions which have version requirements in it (see Wichert's comments on the original thread).
I'm not sure I understand this.
We're supposed to be maintaining these: see the version requirements in setup.py decision of the steering group: http://docs.zope.org/zopetoolkit/steeringgroup/decisions.html
'0' becomes another name for "trunk" so anything that specified version requirements with a lower bound would need to also include "==0".
* I (and others) use tools to do releases (zest.releaser in my case). These tools are based on this policy. Changing the policy breaks the tools.
The proposed change would make this tool simpler. More importantly, it makes things simpler for people who don't use the tool.
* change with little gain (and some loss)
I don't see a loss.
to a policy which we've had for years and works fine. (Philipp wrote this sometime in 2007 or so, and we were already having debates about doing VBs back then. Christian added it in the documentation that turned into the ZTK documentation right away)
Right, Philipp wrote a process that was pretty good. People followed it and in the process we found it could be improved.
I'm also particularly disgruntled that people just started deviating from the ZTK policy without discussion. Goes completely against the point of having a steering group and a written down policy.
I'm sorry you're disgruntled. I wasn't aware that this was a ZTK policy. I've been using '0' since before there was a ZTK. I never proposed it as any sort of standard before, because I wanted to try it for a while first and see if it was an improvement.
Comments like "I don't understand why this should be important" don't improve my mood. The whole point of writing down policy is so everybody knows what it is and will use it, instead of it being some randomly evolving community practice.
Not everything is of equal importance. I don't consider this very important, other than that it seems to be important to you.
This way it is much easier to help new people get up to speed in our community, maintain consistent practices, and people already in our community will also have an easier time keeping track of what's going on.
[I hope people who appreciate having such a policy will chip in here and say "yes, I want a written-down policy, please" so it isn't just me who is telling Jim this.]
I don't mind if there are standards and I wasn't proposing that there shouldn't be. I was proposing a change to the standard. For ZTK packages, I'm willing to follow the standard. I don't agree with this particular standard and won't follow it for my own non-ZTK packages. Jim -- Jim Fulton
On Fri, Sep 11, 2009 at 10:41 AM, Jim Fulton <jim@zope.com> wrote:
On Fri, Sep 11, 2009 at 10:11 AM, Martijn Faassen <faassen@startifact.com> wrote:
* I (and others) use tools to do releases (zest.releaser in my case). These tools are based on this policy. Changing the policy breaks the tools.
The proposed change would make this tool simpler. More importantly, it makes things simpler for people who don't use the tool.
+1 -- reducing the number of tools necessary to (easily) accomplish a particular task is valuable. -- Benji York Senior Software Engineer Zope Corporation
On 2009-09-11, Benji York <benji@zope.com> wrote:
On Fri, Sep 11, 2009 at 10:41 AM, Jim Fulton <jim@zope.com> wrote:
On Fri, Sep 11, 2009 at 10:11 AM, Martijn Faassen <faassen@startifact.com> wrote:
* I (and others) use tools to do releases (zest.releaser in my case). These tools are based on this policy. Changing the policy breaks the tools.
The proposed change would make this tool simpler.
zest.releaser's job would not become simpler. It currently grabs the version (with or without dev marker) from either version.txt (old projects or non-setup.py stuff) or the setup.py. Suddenly it is '0' instead of '1.2dev'. What's it going to suggest as new version? Yeah, it grabs the tags from subversion so it *can* make a decent guess. But you cannot easily register "I want this to become 2.0" anymore.
More importantly, it makes things simpler for people who don't use the tool. +1 -- reducing the number of tools necessary to (easily) accomplish a particular task is valuable.
I'd rather do a "bin/fullrelease" (one step) instead of following a 7-step method to properly release a package. And setting the version to 0 only adds one more potential error point: where do you look up the next version? Someone might have forgotten to tag the previous release (if you look at tags) or might have forgotten to update the CHANGES.txt (if you look at that) or have not uploaded it to pypi (if you look at that). People aren't that good at repetitive tasks. Use a small tool like zest.releaser (or collective.releaser if you don't mind occasional 1.2-r1234 releases as that uses the setup.cfg for the dev marker). Use such a tool and you won't have to bash yourself or co-workers for - forgetting to tag a release. - forgetting to use 'register' in 'sdist upload register' so that the documentation on pypi isn't updated. - forgetting to remove a dev marker (or changing the 0). - Updating the changelog, preparing it for the next changes. Well, we might as well do away with buildout. Reducing the number of tools... Just do it by hand! Reinout -- Reinout van Rees - reinout@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com "Military engineers build missiles. Civil engineers build targets"
Jim Fulton wrote:
* it breaks dependencies on development versions which have version requirements in it (see Wichert's comments on the original thread).
I'm not sure I understand this.
I think your answer is below, and your solution would be to add a == 0 to the dependencies.
We're supposed to be maintaining these: see the version requirements in setup.py decision of the steering group: http://docs.zope.org/zopetoolkit/steeringgroup/decisions.html
'0' becomes another name for "trunk" so anything that specified version requirements with a lower bound would need to also include "==0".
That affects the ZTK policy I mentioned above. It would also need to change to support the 0 convention.
* I (and others) use tools to do releases (zest.releaser in my case). These tools are based on this policy. Changing the policy breaks the tools.
The proposed change would make this tool simpler. More importantly, it makes things simpler for people who don't use the tool.
The tool is already there. Making it simpler is not of a major concern, I'd say; that'd only mean extra work at this point. I can see it makes it simpler for people who don't use the tool, though I cannot see the full scope of it yet, as I haven't seen a list of steps people would need to take. It does make the (version-including) dependencies slightly messier to read, however.
* change with little gain (and some loss)
I don't see a loss.
I think just a simple version dependency without the == 0 is simpler to do right, and more likely to be understood by people coming in. You're exchanging a cost in work (doing the vb) that isn't reflected in code with a cost in the dependencies listing in setup.py, that is reflected in code. In addition, there is the cost of change. In particular, making this change involves two policy changes and a tool change. People need to become aware of these changes. [snip]
I'm also particularly disgruntled that people just started deviating from the ZTK policy without discussion. Goes completely against the point of having a steering group and a written down policy.
I'm sorry you're disgruntled. I wasn't aware that this was a ZTK policy.
May I kindly recommend to you as a fellow steering group member that you read about the ZTK policies on the ZTK website? This may help us avoid a few more surprises like this in the future...
I don't mind if there are standards and I wasn't proposing that there shouldn't be. I was proposing a change to the standard. For ZTK packages, I'm willing to follow the standard.
Thanks. Christian Theune and Stephan Richter might both go +1 on this change - perhaps you ask them to read the threads involved and it's quite possible you can convince them for this change. I'd be outvoted. I think a sketch of what this document would look like under the new policy would be useful to see in advance to help with the evaluation: http://docs.zope.org/zopetoolkit/process/releasing-software.html And if the steering group decides in favor of this change, I'd like to ask those in favor of this policy change to adjust the ZTK documents in this case. I take it that all version dependencies in setup.py would need to be modified to include == 0 too, though I imagine this can be done on a case by case basis. I think a description on how one takes a package under development (in combination with an existing package that uses it, such as with an external) would be a valuable addition to our existing documentation.
Not everything is of equal importance. I don't consider this very important, other than that it seems to be important to you.
Let me explain to you what exactly I find important in this matter. * I want to remind people of what the ZTK policy is and not to use the other approach for ZTK packages until that policy is changed. * I want to point out the importance of having a written down policy for things and people actually following it. * I want to make sure that when people want to change a policy, they are aware of the need to discuss it in advance, not after people already started doing different things. * I want to critically discuss the impact of adopting this new policy, comparing it to the old policy, and evaluating the cost of changing. We've seen that this change impacts several existing policies of the ZTK and a tool that at least some people use. All this sounds bureaucratic, but it's better than having all sorts of undocumented policies that newcomers can't figure out at all, and that existing developers have a much harder time to track. I think all these points have been made clear to people involved in this discussion. I'm looking forward to seeing Stephan and Christian's opinions on this change. Regards, Martijn
On 2009-09-11, Martijn Faassen <faassen@startifact.com> wrote:
Jim Fulton wrote:
but if it is, I propose to using 0 instead of the dev of the next version. Where I've used '0', I've found it to be less error prone. Ir also requires less effort because it means you never have to edit the version on the trunk.
I'm -1 to using 0.
-1
Reasons:
* it breaks dependencies on development versions which have version requirements in it (see Wichert's comments on the original thread).
Really important. When I add an external to a trunk/branch version of something as I need to fix/improve something, I immediately change the version requirement in the setup.py. What's better? Do a "my.package > 2.7" or leaving it at "my.package >= 2.5" and trusting your memory to change that afterwards? You'll surely see the "my.package == 0" when releasing (as stuff breaks), which means more work as you have to look up version numbers again. Make it easy to do the right thing instead of making it more work, I'd say. The '0' means it is easier (human nature...) to just leave the version requirement in the setup.py alone as it is too much hassle.
* I (and others) use tools to do releases (zest.releaser in my case). These tools are based on this policy. Changing the policy breaks the tools.
In case the policy is changed, I'll of course fix up the tool. I'm still -1, though :-)
This way it is much easier to help new people get up to speed in our community, maintain consistent practices, and people already in our community will also have an easier time keeping track of what's going on.
A '0' version does little to help people pitching in with a bugfix. They'll have to figure out themselves what the version is supposed to be. If you pick the my.project/branches/reinout-fixthingy branch and the version is set to '0', you'll have to figure out what version of the branch is. A 2.8 bugfix branch? A feature brach off the trunk? The '0' seems especially unclear for branches.
[I hope people who appreciate having such a policy will chip in here and say "yes, I want a written-down policy, please" so it isn't just me who is telling Jim this.]
for i in range(20): print "yes, I want a written-down policy, please" Reinout -- Reinout van Rees - reinout@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com "Military engineers build missiles. Civil engineers build targets"
On Tuesday 15 September 2009, Reinout van Rees wrote:
On 2009-09-11, Martijn Faassen <faassen@startifact.com> wrote:
Jim Fulton wrote:
but if it is, I propose to using 0 instead of the dev of the next version. Where I've used '0', I've found it to be less error prone. Ir also requires less effort because it means you never have to edit the version on the trunk.
I'm -1 to using 0.
-1
-1 from me too. Having the previous version avoids having to look it up in CHANGES.txt or the tags, which is really lame if you do lots of releasing. Regards, Stephan -- Entrepreneur and Software Geek Google me. "Zope Stephan Richter"
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephan Richter wrote:
On Tuesday 15 September 2009, Reinout van Rees wrote:
On 2009-09-11, Martijn Faassen <faassen@startifact.com> wrote:
Jim Fulton wrote:
but if it is, I propose to using 0 instead of the dev of the next version. Where I've used '0', I've found it to be less error prone. Ir also requires less effort because it means you never have to edit the version on the trunk. I'm -1 to using 0. -1
-1 from me too. Having the previous version avoids having to look it up in CHANGES.txt or the tags, which is really lame if you do lots of releasing.
If you are making releases without having the CHANGES.txt open in your browser, then you need to put down the keyboard and back away slowly, so that nobody gets hurt. Reviewing / correcting the changelog (and comparing it with a diff from the last release) should be a fundamental part of making a release. At the very minimum, you're supposed to update the release date in the changelog, right? I *like* the property of the "0" strategy that it makes the job of releasing a package a little harder: releaseing software should be a thoughtful, careful process, not something you do without a bit of hesitation and review. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKr/9i+gerLs4ltQ4RArnjAJsEFhiKH6pyOx9AYsoZVP1W0N3U5wCgivGn jc897TMxlf9XAmW4K/TJjag= =/fhs -----END PGP SIGNATURE-----
On Tue, Sep 15, 2009 at 4:56 PM, Tres Seaver <tseaver@palladion.com> wrote:
I *like* the property of the "0" strategy that it makes the job of releasing a package a little harder: releaseing software should be a thoughtful, careful process, not something you do without a bit of hesitation and review.
Well said. -- Benji York Senior Software Engineer Zope Corporation
On 2009-09-15, Tres Seaver <tseaver@palladion.com> wrote:
If you are making releases without having the CHANGES.txt open in your browser, then you need to put down the keyboard and back away slowly, so that nobody gets hurt. Reviewing / correcting the changelog (and comparing it with a diff from the last release) should be a fundamental part of making a release. At the very minimum, you're supposed to update the release date in the changelog, right?
Checking the changelog: yes, do that. And again, zest.releaser takes the "make doing the right thing simple" approach by providing a "lasttagdiff" command to show the diff of the current checkout with the last tag it can find in svn. For the common case, this helps a lot. And updating the release date? Yes, zest.releaser does that for you so that you never ever forget it. (And yes, it first shows you a diff and asks you to press "yes" so you do get to review it and you're constantly reminded about what's happening).
I *like* the property of the "0" strategy that it makes the job of releasing a package a little harder: releaseing software should be a thoughtful, careful process, not something you do without a bit of hesitation and review.
Seen from a different viewpoint, this also makes it an unappetizing yucky event. Human nature then quickly takes over and tries to find corners to cut. And human nature includes mistakes, so stuff is forgotten (like that forgotten upload to pypi we saw here on the mailinglist). Tres, is your preference something personal or is it something you'd like to see everyone adopt? In that case "my" zest.releaser would be quite high on your things-to-torture list :-) Which would sadden me a bit as my goals were: - make it easy to do the good thing (like an easy diff with the last tag) - make it painless and take the hassle out of it - get more good releases. The '0' would be something zest.releaser could code around, so it would defeat the purpose of making it harder. The loss of clarity would still be there. Reinout -- Reinout van Rees - reinout@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com "Military engineers build missiles. Civil engineers build targets"
Hi
Betreff: Re: [Zope-dev] official release policy ZTK is still not changed
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Stephan Richter wrote:
On Tuesday 15 September 2009, Reinout van Rees wrote:
On 2009-09-11, Martijn Faassen <faassen@startifact.com> wrote:
Jim Fulton wrote:
but if it is, I propose to using 0 instead of the dev of the next version. Where I've used '0', I've found it to be less error prone. Ir also requires less effort because it means you never have to edit the version on the trunk. I'm -1 to using 0. -1
-1 from me too. Having the previous version avoids having to look it up in CHANGES.txt or the tags, which is really lame if you do lots of releasing.
If you are making releases without having the CHANGES.txt open in your browser, then you need to put down the keyboard and back away slowly, so that nobody gets hurt. Reviewing / correcting the changelog (and comparing it with a diff from the last release) should be a fundamental part of making a release. At the very minimum, you're supposed to update the release date in the changelog, right?
I *like* the property of the "0" strategy that it makes the job of releasing a package a little harder: releaseing software should be a thoughtful, careful process, not something you do without a bit of hesitation and review.
I propose to delete the CHANGES.txt file after we tagged the trunk. This will force people to carefully read all the revisions till they will find the removed CHANGES.txt file for restore them. And of corse we should add a comit hook in subversion which will not allow to tag a trunk without a CHANGES.txt file. Hard enough? just kidding, Roger Ineichen
Hi there, Unless you think you have a great argument that you think will make significant portions of the ZTK steering group change their mind on this, this discussion should now be closed. We're sticking with our current release policy for the ZTK packages. This doesn't affect non-ZTK packages; the ZTK steering group explicitly takes no responsibility for those packages. As a personal preference of course I'd like some uniformity in this, but I can live with a divergence. Regards, Martijn
Hey, Stephan Richter wrote: [snip]
-1 from me too. Having the previous version avoids having to look it up in CHANGES.txt or the tags, which is really lame if you do lots of releasing.
From private conversations here at the Grok sprint with Christian I think that means that the steering group has concluded the release policy remains unchanged for the ZTK. For other packages of course other approaches can be taken - the ZTK steering group takes no authority there. Regards, Martijn
Hi, On 09/16/2009 09:19 AM, Martijn Faassen wrote:
Hey,
Stephan Richter wrote: [snip]
-1 from me too. Having the previous version avoids having to look it up in CHANGES.txt or the tags, which is really lame if you do lots of releasing.
From private conversations here at the Grok sprint with Christian I think that means that the steering group has concluded the release policy remains unchanged for the ZTK.
For other packages of course other approaches can be taken - the ZTK steering group takes no authority there.
Thanks Martijn, for stepping in. For the record: As Martijn said I'm -1 on the "0" approach as well. Christian -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development
Hi there, I was doing some thrawling of ZTK packages anyway, and this was easy. So, it appears the following ZTK packages now follow the 'version="0"' convention: zope.copypastemove zope.html zope.app.applicationcontrol zope.app.basicskin zope.app.i18n zope.app.publication zope.app.pythonpage zope.app.security The rest seems to follow the official convention. Depending on the outcome of this discusion we'll need to figure out how to get all the packages in sync with what the policy will be (and describe it). Regards, Martijn
I'm guilty of causing most these packages to violate the standards, while making their tests pass. Jim On Fri, Sep 11, 2009 at 11:39 AM, Martijn Faassen <faassen@startifact.com> wrote:
Hi there,
I was doing some thrawling of ZTK packages anyway, and this was easy. So, it appears the following ZTK packages now follow the 'version="0"' convention:
zope.copypastemove zope.html zope.app.applicationcontrol zope.app.basicskin zope.app.i18n zope.app.publication zope.app.pythonpage zope.app.security
The rest seems to follow the official convention. Depending on the outcome of this discusion we'll need to figure out how to get all the packages in sync with what the policy will be (and describe it).
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 )
-- Jim Fulton
Jim Fulton wrote:
I'm guilty of causing most these packages to violate the standards, while making their tests pass.
Wasn't my intent to track down the guilty, just ran into this information and wanted to record it for posterity. Making their tests pass is of course way more important than this particular standard, so thanks for doing that. :) Regards, Martijn
participants (8)
-
Benji York -
Christian Theune -
Jim Fulton -
Martijn Faassen -
Reinout van Rees -
Roger Ineichen -
Stephan Richter -
Tres Seaver