[Zope3-dev] Zope 3 release planning

[Martijn Faassen]

Dominik Huber wrote:
> Martijn Faassen wrote:
> 
>> *Deploying* software developed against the trunk version is a recipe 
>> for maintenance problems. If I install the trunk at some customer, and 
>> then install the trunk later on at another customer, and then install 
>> my software that depends on features (or bugs) that are in trunk 1 but 
>> aren't in trunk 2, I have a problem.
> 
>> I think the Zope 3 developers currently don't have any other option 
>> (besides using Zope X3.0, which is what I'm using), so I doubt that is 
>> an indication of the community's perspective. I also think there can 
>> be quite a few more Zope 3 developers that aren't present as they 
>> don't feel like developing against the trunk. :)
> 
>> One problem with developing against the trunk is that you know you 
>> can't release it. What am I to tell people? "Check out the trunk of 
>> Zope 3 to try this great software!" doesn't sound very good to me. The 
>> audience is rather small.
>  
> IMO your argumentation paints a little black and white. There are 
> several options such as internal tags or branches
> to avoid those drawbacks and solve all your illustrated use cases quite 
> acceptable.

Not acceptable in my book. I release software to the world, and say, 
look, great software! And then when people try to install it, I inform 
people to download a Zope 3 tag or branch? Or perhaps I packaged it up 
myself? What if people want to install *other* great software too, 
developed by other people that uses a different tag or branch?

It isn't like I'm inventing this idea about releases for Zope 3 or 
anything. Do you typically release Zope 2 products that depend on Zope 2 
trunk features? Or a GTK app that works only with the trunk version of 
GTK? Or Python software against a tag on the Python repository? Or Java 
software against an unreleased JDK?

I'm really somewhat at a loss that I find myself arguing with people 
about the merits of releasing software...

> IMO it was already a problem within Zope 2  to manage your custom 
> application and all different release cycles of the involved products.

It's a problem Infrae has been dealing with for Silva for years now. We 
make sure we develop and test against particular Zope 2 versions and 
product versions and recommend our users to run those. It only works if 
there are actual releases to build on out there, of course. :)

I understand that the Plone community has been struggling with this as 
well, and I've heard people complain about needing particular odd 
versions to make everything work (it'd work with rc1 but not with rc2, 
say). It's a bit harder to manage this for a community as diverse as the 
Plone community, but I'm sure the Plone developers appreciate solid 
releases to build on as well.

> Everybody who observed Zope 3 development deeply enough, should be aware 
> of the circumstance, that their are still a lot of fundamental changes 
> happen. Those changes are caused by growing perceptions of the problem 
> domain. This learning process is only fuzzy predictable and therefore it 
> is pure illusion to demand the same liability like in a software project 
> within a more established state.

I don't understand this. I thought after Zope X3, the fundamental 
changes were slacking off and the API won't be broken anymore unless 
there is an explicit decision made. Luckily Zope 3 a platform 
well-tested and flexible enough to grow and change still, though. One 
way to help people manage this change is regular releases, as:

* changes to the core will be published soon enough, so you know you can
   contribute to the core and have the benefit happen to you within a
   predictable time frame. The Gnome community is an example of where
   this seems to be managed well.

* you can develop and deploy against fixed version of the software, and
   know other people will do so too.

> IMO it is a very costly and unsatisfying decision to stay with 3.0.0 at 
> the moment.

Costly and unsatisfying for whom? I'm not sure what decision we're 
talking about here. You mean developers' decision to develop against a 
stable, released platform?

> I would suggest to people who can't accept the consequences 
> of early adapting a technology to stay with Zope 2 until the fundamental 
> changes are gone, because you still would have to change your code even 
> if theire are plenty of releases during that time. 

I thought the point where the fundamental changes stop happening already 
took place, at X3.0.0. When are the fundamental changes going to stop, 
in your opinion? It's not like Zope 3 hasn't been in development for 
some time now.

> IMO it's also an 
> illusion to belive the update-your-code-and-solve-all-your-problem 
> script will be shipped within the release.

Sure, and I am not asking for that.

Regards,

Martijn