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 _______________________________________________ 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 )