Zope feature freeze project ??
Hello, as many of you, I am driving a zope based platform for a business. What happen with Zope developpment ? Like most of the Public software, the developpment is a mix of bug fixes and feature adds. It's like the life :-) Feature adds means a lack of compatibility with the "mass" of products installed on your working platform, which means moving all this products to follow the fast developping speed of Zope... But, how many time do you need the new features ? When you have developped the platform the first time, you did a great work, and now you only want to keep it alive at a low cost. Bug Fixes mean that you will not stay for hours and days investigating why something is failling, and avoiding the cracking of the sysem. So you need it. There is an alternative way, which is the development of a Zope with feature freeze, and only bug fixes. And I think it is surely more economic and secure than updating all the products. Well, in my case I am with Zope 2.4.4b2, and I don't want to upgrade to Zope 2.5. I still remembre when I started the developpment with 2.4, almost none of the Zope 2.3 products worked !!! So I am looking for: 1) A software tool to manage this "feature freeze" developpment (I suppose that a very good cvs system, to differentiate the bug fixes and the feature adds, from the zope head developpment). I have looked for a generic system, and a generic community, but I haven't find anything yet. 2) People with the same needs. 3) Tell and explain me why I am wrong. Thanks :-) -- __o _ \<_ (_)/(_) Saludos de Julián -.- DVD-record Tools for linux http://www.freesoftware.fsf.org/dvdrtools/
On Monday 09 Sep 2002 11:23 am, Julián Muñoz wrote:
1) A software tool to manage this "feature freeze" developpment (I suppose that a very good cvs system, to differentiate the bug fixes and the feature adds, from the zope head developpment). I have looked for a generic system, and a generic community, but I haven't find anything yet.
There has been some brief discussion about this on zope-coders recently, centered around the desire to have fewer hot-fixes, possibly by having less traumatic 0.0.x releases.
2) People with the same needs.
The proportion of such people increases as the Zope community grows. All you have to do is wait ;-)
On Mon, 9 Sep 2002, [ISO-8859-1] Juli�n Mu�oz wrote:
Feature adds means a lack of compatibility with the "mass" of products installed on your working platform, which means moving all this products to follow the fast developping speed of Zope... With zope 2.5 I have not had any of my zope 2.4 products break and there where new features added. New features does not mean that things break.
But, how many time do you need the new features ? When you have developped the platform the first time, you did a great work, and now you only want to keep it alive at a low cost.
Often our customers ask for more things over time so it is easier to just continue to develop our python products to give more functionality and when they need new features that we have developed we test it with our newest python products and zope combination and if everything works we upgrade to that. We have not had any problems doing that.
Bug Fixes mean that you will not stay for hours and days investigating why something is failling, and avoiding the cracking of the sysem. So you need it.
Yes we definitely need bug fixes.
There is an alternative way, which is the development of a Zope with feature freeze, and only bug fixes. And I think it is surely more economic and secure than updating all the products.
Overall I would agree there should be a feature freeze x weeks before a new version is released and after that point only bug fixes would be allowed in.
Well, in my case I am with Zope 2.4.4b2, and I don't want to upgrade to Zope 2.5. I still remembre when I started the developpment with 2.4, almost none of the Zope 2.3 products worked !!!
Why don't you want to upgrade to zope 2.5.1? It has a lot of fixes and it is the most stable release I have used so far. However why not test what you have with zope 2.5.1 and see if it all works? It is trivial to upgrade zope so I dont' really see a problem. Also if you work with python products instead of zclasses and take the time to design them it should take a few minutes at most to resolve changed to a new version of zope if that. You do design your python products right? I mean how can you be upset with maintenance if you did not design stuff very well to begin with.
2) People with the same needs. My needs are that they document what stuff breaks backwards compat and that I can modify my python product so it will still load the data. If zope 3.x breaks my product and I have to fix it up that does not really bother me since it shouldn't take me then 5-10 hours to fix it back up however it needs to be possible to fix it back up becuase I can not lose data compatibility otherwise I will have to stay with older versions of zope.
3) Tell and explain me why I am wrong.
Already covered and I agree with some of what you say.
Thanks :-) np :)
Designing and building web applications http://webme-eng.com
On Mon, 9 Sep 2002 kosh@aesaeion.com wrote:
Why don't you want to upgrade to zope 2.5.1? It has a lot of fixes and it is the most stable release I have used so far.
Ok, nice to hear this.
However why not test what you have with zope 2.5.1 and see if it all works? It is trivial to upgrade zope so I dont' really see a problem. Also if you work with python products instead of zclasses and take the time to design them it should take a few minutes at most to resolve changed to a new version of zope if that.
Well, my experience is that it is terribly difficult to have a stable product, it take time, and when you change the platform version (zope), my products will go back to prehistory from a point of view of stability... (new bugs, "strange things", etc...)
You do design your python products right? I mean how can you be upset with maintenance if you did not design stuff very well to begin with.
Maintenance is needed. But it's good to think also what kind of maintenance is not needed, so I can do better the needed maintenance :-) -- __o _ \<_ (_)/(_) Saludos de Julián -.- DVD-record Tools for linux http://www.freesoftware.fsf.org/dvdrtools/
However why not test what you have with zope 2.5.1 and see if it all works? It is trivial to upgrade zope so I dont' really see a problem. Also if you work with python products instead of zclasses and take the time to design them it should take a few minutes at most to resolve changed to a new version of zope if that.
Well, my experience is that it is terribly difficult to have a stable product, it take time, and when you change the platform version (zope), my products will go back to prehistory from a point of view of stability... (new bugs, "strange things", etc...)
why is it difficult to have a stable product? if you write python products and not zclasses there is no reason for a product to become "unstable". just as a data point, i have written python products for zope for years now and i do not recall ever having to apply patches just to make something compatible with a newer version of zope. i write patches or even rewrite products to take advantage of new things in newer zope releases. that's it. jens
Jens Vagelpohl wrote:
why is it difficult to have a stable product? if you write python products and not zclasses there is no reason for a product to become "unstable".
just as a data point, i have written python products for zope for years now and i do not recall ever having to apply patches just to make something compatible with a newer version of zope. i write patches or even rewrite products to take advantage of new things in newer zope releases. that's it.
Ditto ... well actually I had to change a few Products as the DateTime package changed location in the file tree. regards Max M
<evolve>
=?ISO-8859-1?Q?Juli=E1n_Mu=F1oz?= writes:
... feature freezed Zope version ... 3) Tell and explain me why I am wrong. I am following the Zope development since 2.1.6 up to Zope 2.5.1 (usually the CVS branch).
I had no or negligible work with these upgrades with two exceptions: * 2 days for Zope 2.1.6 to Zope 2.3.3 (you see, I did not try Zope 2.2). This was due to dramatic changes with respect to the security policy * 1 day for CMF 1.2 to CMF 1.3 (with DCWorkflow) This was due to incompatible extensions done by me and Flaurent to DCWorkflow and drastic changes in the way objects are catalogued during copy/move. All in all, I did not meet your problem. Furthermore, following your idea, you will end up with bugfix releases for each major Zope version. Not even companies like Oracle (that get big money from support contracts) can do this. Even they stop support for older releases... Dieter
So really it is "cheaper" to upgrade the products than to backport the bugfixes ? I my mind I have the idea of Debian Potato. Stable for years, bugfixes backported for years, it is the paradise (for the system administrator)! Why shouldn't be the experience of Debian Potato valid for Zope ? Julián On Mon, 9 Sep 2002, Dieter Maurer wrote:
=?ISO-8859-1?Q?Juli=E1n_Mu=F1oz?= writes:
... feature freezed Zope version ... 3) Tell and explain me why I am wrong. I am following the Zope development since 2.1.6 up to Zope 2.5.1 (usually the CVS branch).
I had no or negligible work with these upgrades with two exceptions:
* 2 days for Zope 2.1.6 to Zope 2.3.3 (you see, I did not try Zope 2.2).
This was due to dramatic changes with respect to the security policy
* 1 day for CMF 1.2 to CMF 1.3 (with DCWorkflow)
This was due to incompatible extensions done by me and Flaurent to DCWorkflow and drastic changes in the way objects are catalogued during copy/move.
All in all, I did not meet your problem.
Furthermore, following your idea, you will end up with bugfix releases for each major Zope version. Not even companies like Oracle (that get big money from support contracts) can do this. Even they stop support for older releases...
Dieter
Juli=?iso-8859-1?Q?=E1n?= Mu=?iso-8859-1?Q?=F1oz?= writes:
So really it is "cheaper" to upgrade the products than to backport the bugfixes ? Usually, I do not upgrade to get bugs fixed but to get new features: e.g. Python Scripts (2.1 -> 2.3), ZPT/Sessions (2.4 -> 2.5).
Usually, I do not need bug fixes. I find bugs usually during project development. I cannot remember that I had a need to fix bugs after development has been complete (this does not mean, that it never happened, just that it occurs very infrequently). Dieter
I am following the Zope development since 2.1.6 up to Zope 2.5.1 (usually the CVS branch).
I had no or negligible work with these upgrades with two exceptions:
Do you use ZClasses? Upgrading ZClasses from Zope 2.4.x to Zope 2.5.x was a real pain. Recently, a Zope Corp. employee said on this list something to the effect that "as little development effort is now dedicated to ZClasses as possible". Are ZClasses officially obsolete? -- Milos Prudek
Milos Prudek wrote:
I am following the Zope development since 2.1.6 up to Zope 2.5.1 (usually the CVS branch).
I had no or negligible work with these upgrades with two exceptions:
Do you use ZClasses?
Upgrading ZClasses from Zope 2.4.x to Zope 2.5.x was a real pain.
Recently, a Zope Corp. employee said on this list something to the effect that "as little development effort is now dedicated to ZClasses as possible".
Are ZClasses officially obsolete?
I do not belive they are officially obsolete. However, I would categorize ZClasses as a prototyping tool; best suited to an application that is going to be tied to a specific version of Zope, or discarded or re-written using Python modules. There are occasionally some issues where ZClasses can become unhooked during upgrades; the ZClass code recevies very little maintenance activity. I do not recommend ZClasses as a foundation for a large, multi-year application. For "small" applications (your defination of small may vary) then ZClasses are very satisfactory, albeit something of an older design paradigm. Newer trends would tend to implement things ZClasses do as CMF skins, for example, with python scripts and page templates (Note: having a bezillion CMF skins isnt a good idea either).
Milos Prudek writes:
I am following the Zope development since 2.1.6 up to Zope 2.5.1 (usually the CVS branch).
I had no or negligible work with these upgrades with two exceptions:
Do you use ZClasses? I do.
Upgrading ZClasses from Zope 2.4.x to Zope 2.5.x was a real pain. I never had ZClass problems while upgrading.
Dieter
From: "Julián Muñoz" <jmunoz@telefonica.net>
There is an alternative way, which is the development of a Zope with feature freeze, and only bug fixes. And I think it is surely more economic and secure than updating all the products.
This is already how things are done. Both 2.4.3 and 2.4.4 are bug fix releases that was made after 2.5.0, for example. But this can only go on for a while, then you are expected to upgrade. Nobody does bug fixed on Zope 2.3 anymore, for example. If you want to stay with 2.4 forever, you can. You can check out Zope 2.4 from the Zope CVS, and you can merge in new bugfixes into that branch. But quite soon you'll notice that the bugfixes won't be mergeable, because they are dependant on later reorganisations that you don't have. I our experience, "staying behind" is not the most efficient option if you are doing development on Zope. After around 6 to 12 months of being behind on the development you will have spent more time working around the bugs and replacing the missing features of newer version than you would have spent in upgrading. If you want to be bug free, skip the x.x.0 releases, but when x.x.1 comes, upgrading will probably be the most time efficient option. If you don't do any new development at all, but just have a site to manage, then of course you don't need to upgrade at all, unless you suddenly find a bug that haven't bothered you before. Best Regards Lennart Regebro, Torped http://www.easypublisher.com/
On Thursday 12 September 2002 07:08 am, Lennart Regebro wrote: [snip]
If you don't do any new development at all, but just have a site to manage, then of course you don't need to upgrade at all, unless you suddenly find a bug that haven't bothered you before.
And on the upside, security hotfixes are released for old Zope versions retroactively long after those versions stop receiving general maintenance. -Casey
On Thu, 12 Sep 2002, Lennart Regebro wrote:
I our experience, "staying behind" is not the most efficient option if you are doing development on Zope. After around 6 to 12 months of being behind on the development you will have spent more time working around the bugs and replacing the missing features of newer version than you would have spent in upgrading.
(...) Yes, I believe it now. Many people say the same ;-) I have to think more deeply on the analogy between Debian Potato and Zope.
If you don't do any new development at all, but just have a site to manage, then of course you don't need to upgrade at all, unless you suddenly find a bug that haven't bothered you before.
Yes, and this allway happens, at less for the security bugs.
Best Regards
Lennart Regebro, Torped http://www.easypublisher.com/
-- __o _ \<_ (_)/(_) Saludos de Julián -.- DVD-record Tools for linux http://www.freesoftware.fsf.org/dvdrtools/
participants (10)
-
Casey Duncan -
Dieter Maurer -
Jens Vagelpohl -
Julián Muñoz -
kosh＠aesaeion.com -
Lennart Regebro -
Matthew T. Kromer -
Max M -
Milos Prudek -
Toby Dickenson