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@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
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
