[Zope3-dev] Re: Release management refinements

[Philipp von Weitershausen]

Stephan Richter wrote:
> On Wednesday 13 September 2006 13:28, Philipp von Weitershausen wrote:
>> Contributing to a community also means adapting to its processes and way
>> of working. The process has been working well for Zope 2 developers, so
>> I don't see why it can't work for Zope 3.
> 
> A couple of comments:
> 
> First, if several -- as in a majority of -- people say "I work this way W.", 
> then our process should be adapted to those people. Having those people 
> contribute less, because of an unnecessary barrier.

Agreed. But we'll have to make compromises between the comfort for the 
developers and the necessary house keeping that we inevitably have to 
commit ourselves to as a serious software project. The latter invariably 
includes maintaining old releases.

Frankly, I personally don't feel very strongly where you commit a fix 
first, as long as the fix gets into all the necessary places. All I know 
is that the described way of working

  a) ensures that you don't "forget" to backport the fix

  b) works for many people

I'm also strongly wondering whether the "majority" of the people 
actually do develop against the trunk.

> Second, Zope 2 and 3 are *very* different in this respect. Zope 2 does not 
> have the same testing story. In Zope 2 it was risky, if not impossible, to 
> use the trunk, because those large frameworks (CMF, Plone, ...) that had very 
> tight couplings with Zope 2 had to be adjusted in many cases.

Sorry, but when was the last time you contributed to Zope 2? You're 
using the past tense which is applicable to most of this. Zope 2 *does* 
have a testing story now. We can't make the past go away, but we have 
the same standard in terms of testing as Zope 3 does now. (And as far as 
the cutting-edge Plonistas are concerned, for example, they often do 
develop against the trunk or at least the latest development release 
branch).

Plus, I don't see the point in the testing argument. Just because the 
Zope 3 trunk can be considered "more stable" (for some definition of 
stable) doesn't mean we can neglect stable releases branches.

> Zope 3 is different, since the trunk is effectively as stable as any release 
> at any time, especially now with the even stricter trunk policies and the 
> desire to move packages out of the core. This allows developers to develop 
> against the trunk.

I never said that that was a bad idea.

> And even if the trunk is shaken by deprecation warnings like your 
> refactorings, most packages based on Zope 3 were updated within a week, even 
> large projects like SchoolTool and Tiks. This is a very strong statement and 
> warrants a different check-in policy.

I disagree. I think the majority of those who do web development with 
Zope3 nowadays use releases. Gocept seems to do it, I do it, and most 
zope3-users at zope.org people seem to do it as well. Zope 3 isn't all 
about "the trunk is our playground" anymore. Again, I have nothing 
against development against the trunk, but thinking that this is the 
standard development model is mistaken.

> To get into an even more fundamental discussion, I claim that the culture of 
> test-driven development weakens some common software-engineering practices, 
> such as release cycles. I think, and seeing our discussions it seems I am 
> right, that releases are marketing tools, not important software engineering 
> artifacts. Releases allow us to say, "Here are those great new features.",
> write a magazine article, be slashdotted, and tell the client we are already 
> in version 3.X where X > 100.
> 
> Don't get me wrong, I understand the motivations behind releases, besides 
> those points. It allows other developers to have a set target  and something 
> to rely on, etc. Thus I said, it "weakens" the release artifact, not 
> "obsolete" it.

I think the most important fact about releases, strictly speaking from a 
software development view, is that they're milestones in terms of 
feature stability. We promise not to introduce new features and not to 
shake up things within a stable release branch. People want this sort of 
stability insurance (with the additional bugfix promise).

Philipp