Hi there, Since Zope 2.8 has now been released, we can start talking about what would be in Zope 2.9. I have some ideas: * newer version of Five included (whatever version is current then) * Zope 3.1 included * Python 2.4 support I think these could all be accomplished without getting too ambitious. Especially the Five work and Zope 3.1 work will mostly happen anyway, so integration should be relatively easy. I don't know much about how involved Python 2.4 support would be; perhaps people who know more can speak up. Then there's something I know little about, but is also believed planned for Zope 2.9: * blob storage, file iterators I believe the work on this is fairly far along already. I'd be happy if this was *all* that changed in Zope 2.9. This way we can release Zope 2.9 in the forseeable future, like, late this year. If Zope 3 is on track there will already be a Zope 3.2 release imminent by then, but I'm okay with Zope 2.x running a version behind in the name of getting things out of the door to the developers. What do people think? Regards, Martijn
Am 17.06.2005 um 11:45 schrieb Martijn Faassen:
Hi there,
Since Zope 2.8 has now been released, we can start talking about what would be in Zope 2.9. I have some ideas:
* newer version of Five included (whatever version is current then)
* Zope 3.1 included
* Python 2.4 support
+1 although 2.4 support is mainly a policy and auditing process, as some are apparently already running zope on python 2.4. How is this auditing performed?
I think these could all be accomplished without getting too ambitious. Especially the Five work and Zope 3.1 work will mostly happen anyway, so integration should be relatively easy. I don't know much about how involved Python 2.4 support would be; perhaps people who know more can speak up.
Then there's something I know little about, but is also believed planned for Zope 2.9:
* blob storage, file iterators If I'm not mistaken, file iterators are already part of Zope2.8 or do you mean the interaction between blob storage and file iterators?
Looking forward to it, __Janko
--On 17. Juni 2005 11:45:49 +0200 Martijn Faassen <faassen@infrae.com> wrote:
Hi there,
Since Zope 2.8 has now been released, we can start talking about what would be in Zope 2.9. I have some ideas:
* newer version of Five included (whatever version is current then)
* Zope 3.1 included
* Python 2.4 support
I think these could all be accomplished without getting too ambitious. Especially the Five work and Zope 3.1 work will mostly happen anyway, so integration should be relatively easy. I don't know much about how involved Python 2.4 support would be; perhaps people who know more can speak up.
Then there's something I know little about, but is also believed planned for Zope 2.9:
* blob storage, file iterators
I believe the work on this is fairly far along already.
I'd be happy if this was *all* that changed in Zope 2.9. This way we can release Zope 2.9 in the forseeable future, like, late this year. If Zope 3 is on track there will already be a Zope 3.2 release imminent by then, but I'm okay with Zope 2.x running a version behind in the name of getting things out of the door to the developers.
I think (or better hope) that the next 2.9 release won't be as painful as the 2.8 release since the planned feature and there are much more people that know about Five and Zope 3 than about ZODB/MVCC/ZClasses which caused the bottleneck in the 2.8 development. Depending on how Zope 3.2 will be released it would be cool to have 2.9 shipped with Zope 3.2. I don#t know about the 3.2 release schedule. Possibly we could focus on a 2.9 release in fall (October)... we might also look what ZC has in their bags (based on Rob's ZF announcement). Andreas
Andreas Jung wrote: [snip]
Depending on how Zope 3.2 will be released it would be cool to have 2.9 shipped with Zope 3.2. I don#t know about the 3.2 release schedule. Possibly we could focus on a 2.9 release in fall (October)...
I don't expect Zope 3.2 will be released by october. Jim is talking about a 6 month release schedule for Zope 3 last I heard, and 3.1 is not even out yet. I don't think we should hold up Zope 2.9 by waiting for Zope 3 versions, just like we haven't done so with Zope 2.8, which otherwise still would remain unreleased. Regards, Martijn
--On 17. Juni 2005 13:34:34 +0200 Martijn Faassen <faassen@infrae.com> wrote:
Andreas Jung wrote: [snip]
Depending on how Zope 3.2 will be released it would be cool to have 2.9 shipped with Zope 3.2. I don#t know about the 3.2 release schedule. Possibly we could focus on a 2.9 release in fall (October)...
I don't expect Zope 3.2 will be released by october. Jim is talking about a 6 month release schedule for Zope 3 last I heard, and 3.1 is not even out yet. I don't think we should hold up Zope 2.9 by waiting for Zope 3 versions, just like we haven't done so with Zope 2.8, which otherwise still would remain unreleased.
I think the decision could be made short before the release. If 2.9 takes longer than expected and when you guys have Five 1.X for Zope 3.2 then we can include it or ship 2.8 with Five 1.1 and Zope 3.1...I assume that is not such a big task to exchange the Five and Zope 3 code in the Zope 2.9 core. -aj
Andreas Jung wrote:
--On 17. Juni 2005 13:34:34 +0200 Martijn Faassen <faassen@infrae.com> wrote:
Andreas Jung wrote: [snip]
Depending on how Zope 3.2 will be released it would be cool to have 2.9 shipped with Zope 3.2. I don#t know about the 3.2 release schedule. Possibly we could focus on a 2.9 release in fall (October)...
I don't expect Zope 3.2 will be released by october. Jim is talking about a 6 month release schedule for Zope 3 last I heard, and 3.1 is not even out yet. I don't think we should hold up Zope 2.9 by waiting for Zope 3 versions, just like we haven't done so with Zope 2.8, which otherwise still would remain unreleased.
I think the decision could be made short before the release. If 2.9 takes longer than expected and when you guys have Five 1.X for Zope 3.2 then we can include it or ship 2.8 with Five 1.1 and Zope 3.1...I assume that is not such a big task to exchange the Five and Zope 3 code in the Zope 2.9 core.
Yes, I agree we should make this decision before the release. Not shortly before the release, but some months before the date for which the release is planned. I want the Zope 2.9 release to be planned, so that issues like "taking longer than expected" will be less likely. So based on that and on the idea we want to do a Zope 2.9 release late this year, I just think it's unrealistic there'll be a Zope 3.2 release before then. Something may always drastically change though and we should be open to that. What I just want to avoid is having a situation where the Zope 2.9 release is *waiting* for a Zope 3.2 release. Regards, Martijn
I'd be happy if this was *all* that changed in Zope 2.9. This way we can release Zope 2.9 in the forseeable future, like, late this year. If Zope 3 is on track there will already be a Zope 3.2 release imminent by then, but I'm okay with Zope 2.x running a version behind in the name of getting things out of the door to the developers.
+10 on a less ambitious change set than what we had for 2.8... Concentration on consolidation and bug fixing in the massive 2.8 change set would be a very worthy goal for 2.9. jens
On 6/17/05, Martijn Faassen <faassen@infrae.com> wrote:
What do people think?
Just an idea: One thing that would be interesting and increase the Z3 compatibility is to use traversing adapters, and then, of course, make a default adapter that implements Zope2 traversing for objects that does not have a traversing adapter. Stupid or brilliant? :) Even if it is brilliant, there is no particular reason that we can't wait for Zope 2.10, though. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/
Lennart Regebro wrote:
On 6/17/05, Martijn Faassen <faassen@infrae.com> wrote:
What do people think?
Just an idea: One thing that would be interesting and increase the Z3 compatibility is to use traversing adapters, and then, of course, make a default adapter that implements Zope2 traversing for objects that does not have a traversing adapter.
Stupid or brilliant? :)
I know Florent had some ideas of doing this integration too. It's an interesting idea. That said, I don't think we should add this to Zope 2.9, unless a developer gets really enthusiastic in the near future and takes responsibility for this.
Even if it is brilliant, there is no particular reason that we can't wait for Zope 2.10, though.
Exactly. Regards, Martijn
Just an idea: One thing that would be interesting and increase the Z3 compatibility is to use traversing adapters, and then, of course, make a default adapter that implements Zope2 traversing for objects that does not have a traversing adapter.
Stupid or brilliant? :)
I know Florent had some ideas of doing this integration too. It's an interesting idea.
That said, I don't think we should add this to Zope 2.9, unless a developer gets really enthusiastic in the near future and takes responsibility for this.
My idea was to do a big cleanup of Zope 2's traversal mechanisms. The problem is that it will by necessity get rid some of the idiosyncrasies (read: cruft and incoherences) of the current one, and in the process probably break stuff. Which means it has to be optional, which adds even more complexity to the code :( So in the end the realities of backward compatibility are a big hurdle. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg@nuxeo.com
Florent Guillaume wrote:
Just an idea: One thing that would be interesting and increase the Z3 compatibility is to use traversing adapters, and then, of course, make a default adapter that implements Zope2 traversing for objects that does not have a traversing adapter.
Stupid or brilliant? :)
I know Florent had some ideas of doing this integration too. It's an interesting idea.
That said, I don't think we should add this to Zope 2.9, unless a developer gets really enthusiastic in the near future and takes responsibility for this.
My idea was to do a big cleanup of Zope 2's traversal mechanisms. The problem is that it will by necessity get rid some of the idiosyncrasies (read: cruft and incoherences) of the current one, and in the process probably break stuff. Which means it has to be optional, which adds even more complexity to the code :( So in the end the realities of backward compatibility are a big hurdle.
Yes, this is hard, but we need to do things like this. In the short term, it make make the code uglier, due to the backward compatibility code, but we'll be on the road to cleaning it up because we will have provided deprecation warnings letting people know about the coming changes. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Martijn Faassen wrote:
Hi there,
Since Zope 2.8 has now been released, we can start talking about what would be in Zope 2.9.
Yup. I'll just remind everybody that, starting with Zope 2.9 and Zope 3.2, we are switching to time based, rather than feature-based releases. We will make feature releases of Zope 2 and Zope 3 every 6 months, starting this December. I suggest a manditory feature freeze at the beginning of the previous month, so November 1 for the next releases.
I have some ideas:
* newer version of Five included (whatever version is current then)
* Zope 3.1 included
Actually, Zope 3.2. Zope 3.2 and 2.9 will be released together, There is no need for Zope 2 to be a release behind in it's Zope 3 components.
* Python 2.4 support
I think these could all be accomplished without getting too ambitious.
Yes. I think this is a good starting point. I hope there will be more, but, since we are doing time based release from now on, we'll have what we have.
Especially the Five work and Zope 3.1 work will mostly happen anyway, so integration should be relatively easy. I don't know much about how involved Python 2.4 support would be; perhaps people who know more can speak up.
The biggest issue with new Python versions is a security audit to make sure that new Python features don't create security holes. This is especially problementic for Zope 2's current security architecture, which relies on specialized Python compilers. I would *love* to change Zope 2 to use more of Zope 3's security architecture, although I don't know if I'll have time to do that. If someone wants to volunteer for some deep work, I think this would be extremely valuable.
Then there's something I know little about, but is also believed planned for Zope 2.9:
* blob storage, file iterators
I believe the work on this is fairly far along already.
Yes, probably.
I'd be happy if this was *all* that changed in Zope 2.9. This way we can release Zope 2.9 in the forseeable future, like, late this year. If Zope 3 is on track there will already be a Zope 3.2 release imminent by then, but I'm okay with Zope 2.x running a version behind in the name of getting things out of the door to the developers.
What do people think?
I think it is good to plan work, but, *we will not be bound by a specific set of features*. We are switching to time-based releases for Zope 2 and Zope 3. Further, we will coordinate the releases. Essentially, *Zope* is switching to a new release schedule. Zope will be released every 6 months and the releases will be in two parts, a Zope 2 part that includes the current Zope 3 and a Zope 3 part. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Jim Fulton wrote:
Further, we will coordinate the releases. Essentially, *Zope* is switching to a new release schedule. Zope will be released every 6 months and the releases will be in two parts, a Zope 2 part that includes the current Zope 3 and a Zope 3 part.
Will they have the same relase date or will they be offset by a few months or something? -- hilsen/regards Max M, Denmark http://www.mxm.dk/ IT's Mad Science
Max M wrote:
Jim Fulton wrote:
Further, we will coordinate the releases. Essentially, *Zope* is switching to a new release schedule. Zope will be released every 6 months and the releases will be in two parts, a Zope 2 part that includes the current Zope 3 and a Zope 3 part.
Will they have the same relase date or will they be offset by a few months or something?
They will have the same release date, same announcement, etc. Essentially, a single logical release, with a number of separate release files reflecting different platforms and configurations. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Jim Fulton wrote:
Max M wrote:
Jim Fulton wrote:
Further, we will coordinate the releases. Essentially, *Zope* is switching to a new release schedule. Zope will be released every 6 months and the releases will be in two parts, a Zope 2 part that includes the current Zope 3 and a Zope 3 part.
Will they have the same relase date or will they be offset by a few months or something?
They will have the same release date, same announcement, etc. Essentially, a single logical release, with a number of separate release files reflecting different platforms and configurations.
This definitely gets me worried about coordinating everybody. We need very good planning to pull this off, something we haven't shown in previous Zope 2 or Zope 3 release processes. Perhaps a little ambitious? Regards, Martijn
Martijn Faassen wrote:
Jim Fulton wrote:
Max M wrote:
Jim Fulton wrote:
Further, we will coordinate the releases. Essentially, *Zope* is switching to a new release schedule. Zope will be released every 6 months and the releases will be in two parts, a Zope 2 part that includes the current Zope 3 and a Zope 3 part.
Will they have the same relase date or will they be offset by a few months or something?
They will have the same release date, same announcement, etc. Essentially, a single logical release, with a number of separate release files reflecting different platforms and configurations.
This definitely gets me worried about coordinating everybody. We need very good planning to pull this off, something we haven't shown in previous Zope 2 or Zope 3 release processes. Perhaps a little ambitious?
Actually, I think that time-based releases make planning fairly easy. There *will absolutely* be a Zope (2&3) feature freeze and beta release November 1 (or sooner if we think that this leaves too little time for a beta cycle). There *will* be a final release in December, come hell or high water. If you think this is to ambitious, then lets move the freeze/beta up to give us more time for bug fixes, say October 1? Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Jim Fulton wrote:
Martijn Faassen wrote: [snip]
This definitely gets me worried about coordinating everybody. We need very good planning to pull this off, something we haven't shown in previous Zope 2 or Zope 3 release processes. Perhaps a little ambitious?
Actually, I think that time-based releases make planning fairly easy.
There *will absolutely* be a Zope (2&3) feature freeze and beta release November 1 (or sooner if we think that this leaves too little time for a beta cycle).
There *will* be a final release in December, come hell or high water.
If you think this is to ambitious, then lets move the freeze/beta up to give us more time for bug fixes, say October 1?
No, I think the time period for freezes is okay, and you're right, if we take this approach and take care not to destabilize close to the freeze, it should be possible. I'll just stop worrying for now. :) Regards, Martijn
OK, so becuase of the tomembased release schedule, let's not dicuss what goes in 2.9. let's discuss what features we found most urgent/desirable, so we can start working on that, like now.
--On 19. Juni 2005 11:35:32 +0200 Lennart Regebro <regebro@gmail.com> wrote:
OK, so becuase of the tomembased release schedule, let's not dicuss what goes in 2.9. let's discuss what features we found most urgent/desirable, so we can start working on that, like now.
Propose something :-) -aj
Lennart Regebro wrote:
OK, so becuase of the tomembased release schedule, let's not dicuss what goes in 2.9. let's discuss what features we found most urgent/desirable, so we can start working on that, like now.
I think it's fine to discuss what we want to be in Zope 2.9. This way we can plan for it to actually be there. We just should realize that if nobody does the work in time, it won't actually be in there, but that should only get the pressure up. The hope is that a time-based schedule will actually speed up feature development, not slow it down. But you're right, work should start soon. This is also why I started the discussion now. Regards, Martijn
As I mentioned before, I'd like to see Christian's blob work make it into 2.9. So that's one feature. ;-) On Mon, 2005-06-20 at 09:55 +0200, Martijn Faassen wrote:
Lennart Regebro wrote:
OK, so becuase of the tomembased release schedule, let's not dicuss what goes in 2.9. let's discuss what features we found most urgent/desirable, so we can start working on that, like now.
I think it's fine to discuss what we want to be in Zope 2.9. This way we can plan for it to actually be there.
We just should realize that if nobody does the work in time, it won't actually be in there, but that should only get the pressure up. The hope is that a time-based schedule will actually speed up feature development, not slow it down.
But you're right, work should start soon. This is also why I started the discussion now.
Regards,
Martijn _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Jim Fulton wrote:
Martijn Faassen wrote: [snip] I'll just remind everybody that, starting with Zope 2.9 and Zope 3.2, we are switching to time based, rather than feature-based releases. We will make feature releases of Zope 2 and Zope 3 every 6 months, starting this December. I suggest a manditory feature freeze at the beginning of the previous month, so November 1 for the next releases.
Great!
I have some ideas:
* newer version of Five included (whatever version is current then)
* Zope 3.1 included
Actually, Zope 3.2. Zope 3.2 and 2.9 will be released together, There is no need for Zope 2 to be a release behind in it's Zope 3 components.
If the time based release planning works for Zope 3, fine. I just want to avoid a situation where Zope 2.9 has to wait a long time for a Zope 3.2 release. I'd rather have a release out with Zope 3.1 before then. This may actually indicate we need a Zope 2.9 release in the nearer future which just focuses on including Zope 3.1, and planning for a Zope 2.10 release with 3.2 later. This would break time-releasedness for Zope 2.9, in that we could have it in, say, 3 months, though. I need to think this through.
* Python 2.4 support
I think these could all be accomplished without getting too ambitious.
Yes. I think this is a good starting point. I hope there will be more, but, since we are doing time based release from now on, we'll have what we have.
Agreed, having what we have, and releasing it, should be our motto. [snip]
What do people think?
I think it is good to plan work, but, *we will not be bound by a specific set of features*. We are switching to time-based releases for Zope 2 and Zope 3.
Exactly.
Further, we will coordinate the releases. Essentially, *Zope* is switching to a new release schedule. Zope will be released every 6 months and the releases will be in two parts, a Zope 2 part that includes the current Zope 3 and a Zope 3 part.
I am worried about the interdependency of these releases causing delays, but I am also sure we can avoid this with good planning. Regards, Martijn
Martijn Faassen wrote:
Jim Fulton wrote:
Martijn Faassen wrote:
[snip]
I'll just remind everybody that, starting with Zope 2.9 and Zope 3.2, we are switching to time based, rather than feature-based releases. We will make feature releases of Zope 2 and Zope 3 every 6 months, starting this December. I suggest a manditory feature freeze at the beginning of the previous month, so November 1 for the next releases.
Great!
I have some ideas:
* newer version of Five included (whatever version is current then)
* Zope 3.1 included
Actually, Zope 3.2. Zope 3.2 and 2.9 will be released together, There is no need for Zope 2 to be a release behind in it's Zope 3 components.
If the time based release planning works for Zope 3, fine.
It will. I insist. :)
I just want to avoid a situation where Zope 2.9 has to wait a long time for a Zope 3.2 release. I'd rather have a release out with Zope 3.1 before then.
This may actually indicate we need a Zope 2.9 release in the nearer future which just focuses on including Zope 3.1, and planning for a Zope 2.10 release with 3.2 later. This would break time-releasedness for Zope 2.9, in that we could have it in, say, 3 months, though. I need to think this through.
If people insist on this, I'll go along, but I'd really rather not do this. Let's start the 6-month schedule now and commit to time-based releases. If we do do a 2.9 release earlier just to get Zope 3.1, then I still want to stick to a december release for the next Zope zope release.
Further, we will coordinate the releases. Essentially, *Zope* is switching to a new release schedule. Zope will be released every 6 months and the releases will be in two parts, a Zope 2 part that includes the current Zope 3 and a Zope 3 part.
I am worried about the interdependency of these releases causing delays, but I am also sure we can avoid this with good planning.
We have to. If, by some cance we screw this up in december, then we'll have to move the feature freeze date up relative to the final release. Let's try really hard to make this time-based release idea work. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
--On 17. Juni 2005 08:27:43 -0400 Jim Fulton <jim@zope.com> wrote:
I'll just remind everybody that, starting with Zope 2.9 and Zope 3.2, we are switching to time based, rather than feature-based releases. We will make feature releases of Zope 2 and Zope 3 every 6 months, starting this December. I suggest a manditory feature freeze at the beginning of the previous month, so November 1 for the next releases.
Switching to a time-base schedule is a good thing but several things should be taken into account from the point as release manager slave: - the trunk is no longer a development area. Developments must happen on branches and will be merged into the trunk as soon as the stuff is stable. I won't be acceptable to have half-baked stuff in the trunk. This will hold up the release schedule. - people *must* show *more commitment*. If there are outstanding issues then I do expect that the people in charge work on the resolution in time - this means for me not weeks or months. From my work over the last two years or so I can only say that it is a *very big* pain to run after people to get things fixed. There are some code parts e.g. the ZODB which are known in detail to a handful of persons. I do expect a commitment from these people and especially from the companies these people work for to get a certain amount of resources to help resolve outstanding issues - but not resolving issues somehow but in time. Andreas
On Fri, 2005-06-17 at 15:54 +0200, Andreas Jung wrote:
- the trunk is no longer a development area. Developments must happen on branches and will be merged into the trunk as soon as the stuff is stable. I won't be acceptable to have half-baked stuff in the trunk. This will hold up the release schedule.
Is this a commonly-known thing? I mean, it's fine with me, but I just had no idea. If it's true, I will try to help "enforce" it when I see checkins that violate it. - C
Chris McDonough wrote:
On Fri, 2005-06-17 at 15:54 +0200, Andreas Jung wrote:
- the trunk is no longer a development area. Developments must happen on branches and will be merged into the trunk as soon as the stuff is stable. I won't be acceptable to have half-baked stuff in the trunk. This will hold up the release schedule.
Is this a commonly-known thing? I mean, it's fine with me, but I just had no idea. If it's true, I will try to help "enforce" it when I see checkins that violate it.
This has been Zope 2 develpment policy for years: http://www.zope.org/DevHome/Subversion/ZopeSVNFAQ We haven't been doing this for Zope 3, but I think we need to start doing something like this. The rule for Zope 3 has been that the trunk needs to be stable, but that isn't enough. I think the rule should be that the trunk should be ready to make a beta release at any time. We shouldn't check things into the trunk that would prevent a bets. There is a little bit more flexability for Zope 3 because we don't release the whole repository. The Zope 3 repository tree has parts that aren't and may never be released. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
On 6/17/05, Jim Fulton <jim@zope.com> wrote:
The rule for Zope 3 has been that the trunk needs to be stable, but that isn't enough. I think the rule should be that the trunk should be ready to make a beta release at any time.
+1e79 -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/
--On 17. Juni 2005 10:04:41 -0400 Chris McDonough <chrism@plope.com> wrote:
On Fri, 2005-06-17 at 15:54 +0200, Andreas Jung wrote:
- the trunk is no longer a development area. Developments must happen on branches and will be merged into the trunk as soon as the stuff is stable. I won't be acceptable to have half-baked stuff in the trunk. This will hold up the release schedule.
Is this a commonly-known thing? I mean, it's fine with me, but I just had no idea. If it's true, I will try to help "enforce" it when I see checkins that violate it.
This should be the goal when we would switch. Imagine some use the trunk to implement some very cool feature but it will not get finished in time or has lots of outstanding bugs. When switching to a time-based schedule it would be a lot of work to remove this stuff from the trunk which possibly could break other stuff. Ok, most people already develop on branches and merge their stuff when it is finished. I also have no problems with short-time and isolated developments on the trunk but as soon as a developments affects multiple parts of the core it should be made on a branch only be merged after a review or only when the developer is 110% sure about his work. This means that the trunk should in theory always in a state where we could cut a release from... Andreas
On Fri, 2005-06-17 at 11:45 +0200, Martijn Faassen wrote:
Then there's something I know little about, but is also believed planned for Zope 2.9:
* blob storage, file iterators
Thanks for mentioning this. I'd like to see blob storage get in before 2.9. I think it'd be a good candidate for a 2.8-dot release because it's backwards compatible and optional. It ahould be "done" (needs a bit more testing and some minor implementation decisions) in the next few weeks, I suspect. Filestream iterators are already in 2.8 (they were added somewhere in 2.7). - C
Chris McDonough wrote:
On Fri, 2005-06-17 at 11:45 +0200, Martijn Faassen wrote:
Then there's something I know little about, but is also believed planned for Zope 2.9:
* blob storage, file iterators
Thanks for mentioning this. I'd like to see blob storage get in before 2.9. I think it'd be a good candidate for a 2.8-dot release because it's backwards compatible and optional. It ahould be "done" (needs a bit more testing and some minor implementation decisions) in the next few weeks, I suspect.
It can't go into a bug fix release because it is a new feature. Perhaps you can find a way to release it as an add-on product. It would be good for people to get some experience with it before it is released in a stable release.
Filestream iterators are already in 2.8 (they were added somewhere in 2.7).
Cool. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
On Fri, 2005-06-17 at 10:12 -0400, Jim Fulton wrote:
Thanks for mentioning this. I'd like to see blob storage get in before 2.9. I think it'd be a good candidate for a 2.8-dot release because it's backwards compatible and optional. It ahould be "done" (needs a bit more testing and some minor implementation decisions) in the next few weeks, I suspect.
It can't go into a bug fix release because it is a new feature.
Perhaps you can find a way to release it as an add-on product.
It really can't be released as an add-on Product (big P) for Zope unless we were willing to introduce the ZODB hooks it depends upon within ZODB itself. It would be counterproductive to release it as an add-on product that monkeypatches ZODB. That said, it's really not a Zope feature, it's entirely a ZODB feature (save for the zconfig magic that stitches it in to Zope's config file). I guess there could be some sort of standalone ZODB release that included blobs. If someone expresses a desire for that, I'd be happy to create it along with a tiny Zope product that stitched the blobstorage stuff into Zope's config machinery. But if no one expresses an interest, I probably won't.
It would be good for people to get some experience with it before it is released in a stable release.
We have historically always had the opportunity to introduce features that preserve 100% b/c (like filestream iterators) in point releases. This has worked pretty well for the last few years. - C
Chris McDonough wrote:
On Fri, 2005-06-17 at 10:12 -0400, Jim Fulton wrote:
...
We have historically always had the opportunity to introduce features that preserve 100% b/c (like filestream iterators) in point releases. This has worked pretty well for the last few years.
I wasn't aware of this and I don't think it's a good policy. Feature releases should be backward compatible. Bug-fix releases should be for bug fixes. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
On Fri, 2005-06-17 at 11:04 -0400, Jim Fulton wrote:
Chris McDonough wrote:
On Fri, 2005-06-17 at 10:12 -0400, Jim Fulton wrote:
...
We have historically always had the opportunity to introduce features that preserve 100% b/c (like filestream iterators) in point releases. This has worked pretty well for the last few years.
I wasn't aware of this and I don't think it's a good policy.
Feature releases should be backward compatible. Bug-fix releases should be for bug fixes.
Yup. I think the reality of the situation was that there was such a long stretch between 2.7.0 and 2.8.0 that it became impractical to not do this. But if we go to time based major releases, this becomes irrelevant, so hopefully that works! - C
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jim Fulton wrote:
Chris McDonough wrote:
On Fri, 2005-06-17 at 10:12 -0400, Jim Fulton wrote:
...
We have historically always had the opportunity to introduce features that preserve 100% b/c (like filestream iterators) in point releases. This has worked pretty well for the last few years.
I wasn't aware of this and I don't think it's a good policy.
Feature releases should be backward compatible. Bug-fix releases should be for bug fixes.
Agreed, in theory. In practice, the usual handwave has been to construe the absence of the feature as a bug (with greater or lesser justification). Perhaps we can be more hard-nosed about a "no new features in third-dot releases" policy *after* we get a timeboxed release process in place? I have some recollection that a hard-nosed application of such a policy in ZODB land contributed to the creation of the "dead-end" 3.3 release line, never incorporated in any released Zope2 / Zope3 version. Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCsvsB+gerLs4ltQ4RAkJzAKC/9ZzsDNmhJ7zLC8dOQ77FKowouwCgu5RV iZ9fsxZWKXYVwY5bVZfwA/g= =3/4a -----END PGP SIGNATURE-----
Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jim Fulton wrote:
Chris McDonough wrote:
On Fri, 2005-06-17 at 10:12 -0400, Jim Fulton wrote:
...
We have historically always had the opportunity to introduce features that preserve 100% b/c (like filestream iterators) in point releases. This has worked pretty well for the last few years.
I wasn't aware of this and I don't think it's a good policy.
Feature releases should be backward compatible. Bug-fix releases should be for bug fixes.
Agreed, in theory. In practice, the usual handwave has been to construe the absence of the feature as a bug (with greater or lesser justification).
Perhaps we can be more hard-nosed about a "no new features in third-dot releases" policy *after* we get a timeboxed release process in place? I have some recollection that a hard-nosed application of such a policy in ZODB land contributed to the creation of the "dead-end" 3.3 release line, never incorporated in any released Zope2 / Zope3 version.
Which is just fine IMO. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jim Fulton wrote:
Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jim Fulton wrote:
Chris McDonough wrote:
On Fri, 2005-06-17 at 10:12 -0400, Jim Fulton wrote:
...
We have historically always had the opportunity to introduce features that preserve 100% b/c (like filestream iterators) in point releases. This has worked pretty well for the last few years.
I wasn't aware of this and I don't think it's a good policy.
Feature releases should be backward compatible. Bug-fix releases should be for bug fixes.
Agreed, in theory. In practice, the usual handwave has been to construe the absence of the feature as a bug (with greater or lesser justification).
Perhaps we can be more hard-nosed about a "no new features in third-dot releases" policy *after* we get a timeboxed release process in place? I have some recollection that a hard-nosed application of such a policy in ZODB land contributed to the creation of the "dead-end" 3.3 release line, never incorporated in any released Zope2 / Zope3 version.
Which is just fine IMO.
Such an outcome might be "acceptable", but could hardly be called "desirable." I'll note that a *big* pile of potentially useful ZODB features were pretty much inaccessible to the Zope2 community from the date of the first 3.3a1 release, nearly two years ago[1], until the release of Zope 2.8 last month. This timespan, eerily enough, coincides almost exactly with the life of the Zope 2.7 release cycle[2]. I know how and why the loss happened (I helped *make* it happen, I'm afraid), but I don't want it to happen again. Moving to time-based releases should help with the problem, but we aren't there yet, and won't be for a year (a successful delivery in December could be a fluke). [1] \ http://www.zope.org/Products/ZODB3.3/NEWS.html#what-s-new-in-zodb3-3-3-alpha... [2] http://www.zope.org/Products/Zope/2.7.6/CHANGES.txt Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCswEA+gerLs4ltQ4RAmv6AJ98s+dbAbB81g8lRpcRaDHjcyVpMACgq0Ak GK6MYOUvPrazO5oJDn5xXIo= =1SET -----END PGP SIGNATURE-----
Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jim Fulton wrote:
Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jim Fulton wrote:
Chris McDonough wrote:
On Fri, 2005-06-17 at 10:12 -0400, Jim Fulton wrote:
...
We have historically always had the opportunity to introduce features that preserve 100% b/c (like filestream iterators) in point releases. This has worked pretty well for the last few years.
I wasn't aware of this and I don't think it's a good policy.
Feature releases should be backward compatible. Bug-fix releases should be for bug fixes.
Agreed, in theory. In practice, the usual handwave has been to construe the absence of the feature as a bug (with greater or lesser justification).
Perhaps we can be more hard-nosed about a "no new features in third-dot releases" policy *after* we get a timeboxed release process in place? I have some recollection that a hard-nosed application of such a policy in ZODB land contributed to the creation of the "dead-end" 3.3 release line, never incorporated in any released Zope2 / Zope3 version.
Which is just fine IMO.
Such an outcome might be "acceptable", but could hardly be called "desirable."
I'm not sure what outcome you are refering to. Surely not the "dead-end" of 3.3.
I'll note that a *big* pile of potentially useful ZODB features were pretty much inaccessible to the Zope2 community from the date of the first 3.3a1 release, nearly two years ago[1], until the release of Zope 2.8 last month. This timespan, eerily enough, coincides almost exactly with the life of the Zope 2.7 release cycle[2].
Of course, ZODB 3.3 was technically incompatible with Zope 2.7 because it required new-style classes. There's nothing we could have done to make those features accessable sooner short of a major architectural change which, frankly, we could not afford.
I know how and why the loss happened (I helped *make* it happen, I'm afraid), but I don't want it to happen again. Moving to time-based releases should help with the problem, but we aren't there yet,
Right, we are going there. That's what the discussion is about. We have to start some time. We are going to start in December. We couldn't start for Zope 2.9 or 3.1 because we were already committed to changes that were in and needed time to finish. This won't happen in the future because we know that something can't be checked into the trunk unless it is ready for beta and we know that there will be a definate date for the beta. Anything not in by then won't be in the release.
and won't be for a year (a successful delivery in December could be a fluke).
This makes no sense to me at all. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
[Tres Seaver]
Agreed, in theory. In practice, the usual handwave has been to construe the absence of the feature as a bug (with greater or lesser justification).
Like that's going to change <wink>.
Perhaps we can be more hard-nosed about a "no new features in third-dot releases" policy *after* we get a timeboxed release process in place? I have some recollection that a hard-nosed application of such a policy in ZODB land contributed to the creation of the "dead-end" 3.3 release line, never incorporated in any released Zope2 / Zope3 version.
Various versions of ZODB 3.3 were shipped with various ZopeX3-3.0.0 releases, but ZODB is also used by people who don't run Zope. The latter is why I make "standalone" ZODB releases, which have no dependence at all on Zope. While I have timed ZODB releases entirely based on what various Zopes seem to need, I try to do that in ways that make good sense for standalone-ZODB users too. Starting a ZODB 3.4 for new features (and new deprecations) was necessary for ZODB's "other" users (despite not being crucial for Zope's purposes).
On Fri, 2005-06-17 at 13:00 -0400, Tim Peters wrote:
[Tres Seaver]
Agreed, in theory. In practice, the usual handwave has been to construe the absence of the feature as a bug (with greater or lesser justification).
Like that's going to change <wink>.
Over the last year Tres, Andreas, Tim, Fred, Jim, Florent, Stefan H., Yvo, Sidnei, Christian T., Chris W., Christian T., Mark, Jens, Brian, Tino, Paul W., Lennart, dunny, and Dieter (by proxy ;-) have all contributed code to Zope 2 one degree or another. Policy aside, I trust all of these people implicitly to do the right thing with judging whether a feature should make it into a dot release and I wouldn't complain any of them snuck a minor feature into one. If one of them got out of control (that Tim character is a wild-man!), I'm sure somebody would notice and go hose them down. If time-based releases prove not to work out, I'd hope we could revert to that sort of common-sense defacto process. - C
--On 17. Juni 2005 13:17:13 -0400 Chris McDonough <chrism@plope.com> wrote:
Policy aside, I trust all of these people implicitly to do the right thing with judging whether a feature should make it into a dot release and I wouldn't complain any of them snuck a minor feature into one. If one of them got out of control (that Tim character is a wild-man!), I'm sure somebody would notice and go hose them down.
I agree totally. As RM I would have been task to enforce this policy. But because given the fact we had very long release cycles adding new minor feature was acceptable and worked more or less fine - not perfectly but it worked. Otherwise the complete Z2 development would have stand still. So for me time-based releases will only work if people show responsibility and commitment. -aj
On Fri, Jun 17, 2005 at 10:28:11AM -0400, Chris McDonough wrote:
We have historically always had the opportunity to introduce features that preserve 100% b/c (like filestream iterators) in point releases. This has worked pretty well for the last few years.
Strongly agree. By my count there have been 22 features added between 2.7.1 and 2.7.6 (notably including a heavy overhaul of transient objects and sessioning, addition of the filestream iterator, and a host of improvements to ZopeFind, text file support, test.py, restructured text, etc). That's a hell of a lot of useful stuff that would have had to wait the 16 months between 2.7.0 and 2.8.0. -- Paul Winkler http://www.slinkp.com
On Fri, 2005-06-17 at 12:00 -0400, Paul Winkler wrote:
On Fri, Jun 17, 2005 at 10:28:11AM -0400, Chris McDonough wrote:
We have historically always had the opportunity to introduce features that preserve 100% b/c (like filestream iterators) in point releases. This has worked pretty well for the last few years.
Strongly agree. By my count there have been 22 features added between 2.7.1 and 2.7.6 (notably including a heavy overhaul of transient objects and sessioning, addition of the filestream iterator, and a host of improvements to ZopeFind, text file support, test.py, restructured text, etc).
That's a hell of a lot of useful stuff that would have had to wait the 16 months between 2.7.0 and 2.8.0.
Yup. Even on the 2.6 branch we put in dot-release features of the same ilk. (Probably because the period between 2.6 and 2.7 was roughly the same as the period between 2.7 and 2.8). - C
Paul Winkler wrote:
On Fri, Jun 17, 2005 at 10:28:11AM -0400, Chris McDonough wrote:
We have historically always had the opportunity to introduce features that preserve 100% b/c (like filestream iterators) in point releases. This has worked pretty well for the last few years.
Strongly agree. By my count there have been 22 features added between 2.7.1 and 2.7.6 (notably including a heavy overhaul of transient objects and sessioning, addition of the filestream iterator, and a host of improvements to ZopeFind, text file support, test.py, restructured text, etc).
That's a hell of a lot of useful stuff that would have had to wait the 16 months between 2.7.0 and 2.8.0.
Fortunately, we'll be making feature releases every 6 months, so this should not be a problem. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
On Fri, Jun 17, 2005 at 12:17:27PM -0400, Jim Fulton wrote:
Fortunately, we'll be making feature releases every 6 months, so this should not be a problem.
OK. Assuming the new release process works as intended, fine w/ me. Maybe this should be clarified on the SVN / CVS FAQ pages? -- Paul Winkler http://www.slinkp.com
participants (12)
-
Andreas Jung -
Chris McDonough -
Florent Guillaume -
Janko Hauser -
Jens Vagelpohl -
Jim Fulton -
Lennart Regebro -
Martijn Faassen -
Max M -
Paul Winkler -
Tim Peters -
Tres Seaver