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


Zope3-dev mailing list

Reply via email to