[Zope-dev] SVN: zope.file/branches/ulif-fix-menus/ Do menu-related configuration only if z.a.zcmlfiles is available.

[Tres Seaver]

On 06/05/2012 06:36 AM, Uli Fouquet wrote:
> Hi there,
> 
> On Tue, 05 Jun 2012 03:53:19 -0400 Tres Seaver wrote:
> 
>> On 06/05/2012 03:28 AM, Michael Howitz wrote:
>>> Am 04.06.2012 um 18:30 schrieb Uli Fouquet: […]
>>>> Also updated the 0.6 branch in SVN. Hope that's okay.
>>> 
>>> 
>>> I think there should not be a 0.6 branch as the trunk is still on 
>>> 0.6.*. Usually we only create maintenance branches for
>>> non-current releases.
> 
> Yes, the existence of such a branch surprised me too.
> 
>> That isn't true any longer for the ZTK packages:  I added
>> maintenance branches for all the versions used by ZTK 1.0 / 1.1, and
>> switched the development checkouts for 1.0 / 1.1. to use them.
>> Without that change, the stop-energy of "breaking" a dev build for
>> 1.0 / 1.1 was interfering with ongoing development.
> 
> I see, interesting. But that means a stop-energy for releasing any 
> bugfix release of ZTK packages, doesn't it? At least that seems to be 
> the case if even such minimal changes, that do not change the package 
> API at all, are considered to break the ZTK.

I apologise if I misunderstood the BBB implications of your zope.file
work:  I thought I understood that existing apps might need changes to
keep the menu registrations active.


> I also wonder a bit, why it is neccessary to maintain a 'ZTK-branch' 
> named like a regular maintenance branch, at least for maintenance 
> branches that match the trunk version.

It *is* a maintenance branch (the branch from which 0.6.x releases really
ought to be made).  The fact that the trunk had not (yet) diverged was
merely a happy accident.

> Shouldn't that be named 'ztk-compat', 'ztk-1.0-compat' or similar
> then?

I disagreed with the "just release from the trunk" choice earlier, but
went along with it:  we kept having cases where feature work on the trunk
would break tests in the "released" ZTK dev buildouts.  As the number of
incompatible trunks grew (e.g., dropping compatiblitiy tieh Ptyhon 2.4 /
2.5), it finally became too big a drag on that development to have the
"released" ZTK dev tests using trunks.

> Beside this I thought one major point of dev-builds for ZTKs is to
> _see_ changes in ongoing development of packages that break
> ZTK-compatibility.

Not for *released* ZTK versions:  that should only be so for the ZTK
trunk itself.

> Now you can see such breakages only after a release and when these 
> maintenance branches were updated (or, of course, if one does the ztk 
> tests with local changes before release, which I did - without any
> issues).

We should *not* be looking for the ZTK 1.0 / 1.1 dev buildouts to tell us
that we have "broken" something on a trunk:  new versions of ZTK 1.0.x /
1.1.x should be *very* conservative, accepting only true bugfix updates
to their packages.


>> In this case, version 0.6.1 of the zope.file package was included in
>> ZTK 1.0, but dropped from the ZTK before 1.1.  I'm pretty sure the
>> changes Uli added should *not* be propagated into another ZTK 1.0
>> release:  I think they might break apps deployed against ZTK 1.0:
>> Because of the BBB concerns, I think we may need to re-release a
>> 0.6.3 which reverts the 0.6 branch back to the 0.6.1 state, and make
>> Uli's new stuff available as a 0.7.0 release.
> 
> As the menu config has not gone from 0.6.2 but is only activated 
> conditionally, I am relatively sure, that there are no BBB problems
> with 0.6.2. Everyone who used 0.6.1 should also be able to use 0.6.2
> without any changes to local apps/configs. Or did I miss something
> here?
> 
> The (unconditional) _removal_ of menu configuration might indeed be
> part of some 0.7.x or even 1.0 release, just as Leo suggested. But
> that didn't happen yet.
> 
> I also ran ztk tests (Linux/64bit, Python2.7) with 0.6.2 against ZTKs 
> 1.0, 1.0.7, 1.0dev and got exactly same errors as with 0.6.1 (mainly 
> related to Python version, no hints to problems with 0.6.2).
> 
> I am not strictly against reverting all the stuff and going to 0.7,
> but 'pinning' a package version this way and for these reasons seems,
> hm, not very effective to me.


Again, I apologise for my misunderstanding.  If you are confident that
existing apps won't need any changes when upgrading to 0.6.2, then we
shouldn't need to shuffle the releases.


Tres.
-- 
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com