[Zope-dev] official release policy ZTK is still not changed

[Martijn Faassen]

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