Release schedule for Zope 2.11/3.4?
Hi all, since we are three month late with the current releas, it would make sense to reschedule Zope 2.11/3.4 for July (or was it June) next yr?! If we want to stick with the half-yr cycles, we need to schedule the next release for around March/April next yr. Thoughts? Andreas
Andreas Jung wrote:
since we are three month late with the current releas, it would make sense to reschedule Zope 2.11/3.4 for July (or was it June) next yr?!
Is the reasoning here that since a release cycle has taken 9 months, so should the next? I'm not convinced expanding the release cycle is going to make us be on time more.
If we want to stick with the half-yr cycles, we need to schedule the next release for around March/April next yr. Thoughts?
That's one option. The other option is to stick with the plan and catch up, as Christian Theune proposed. It would mean getting very unambitious, but perhaps that isn't a bad idea. The idea of a release is to have a reasonably stable, known-good version of the trunk, and it doesn't matter that much how much the trunk changes. Anyway, if the main thing holding up *this* release is bugfixes, doing a new release in 3 months shouldn't be a problem, as after all, we've already fixed those bugs this time around. :) Regards, Martijn
--On 12. September 2006 12:28:10 +0200 Martijn Faassen <faassen@infrae.com> wrote:
Andreas Jung wrote:
since we are three month late with the current releas, it would make sense to reschedule Zope 2.11/3.4 for July (or was it June) next yr?!
Is the reasoning here that since a release cycle has taken 9 months, so should the next? I'm not convinced expanding the release cycle is going to make us be on time more.
Not really, just a thought in order to stick with the June/December cycle...but not really an important argument.
If we want to stick with the half-yr cycles, we need to schedule the next release for around March/April next yr. Thoughts?
That's one option. The other option is to stick with the plan and catch up, as Christian Theune proposed. It would mean getting very unambitious, but perhaps that isn't a bad idea. The idea of a release is to have a reasonably stable, known-good version of the trunk, and it doesn't matter that much how much the trunk changes.
Anyway, if the main thing holding up *this* release is bugfixes, doing a new release in 3 months shouldn't be a problem, as after all, we've already fixed those bugs this time around. :)
3 month for a new release cycle is just too short. We should not follow the IMO broken concept of "release early, release often" but to follow "release regular, release solid". At least me I refuse to release something just for the sake of making a release at a certain date. Andreas
Andreas Jung wrote:
--On 12. September 2006 12:28:10 +0200 Martijn Faassen <faassen@infrae.com> wrote: [snip]
Anyway, if the main thing holding up *this* release is bugfixes, doing a new release in 3 months shouldn't be a problem, as after all, we've already fixed those bugs this time around. :)
3 month for a new release cycle is just too short. We should not follow the IMO broken concept of "release early, release often" but to follow "release regular, release solid". At least me I refuse to release something just for the sake of making a release at a certain date.
The goal is not release early, release often, but to get back to our regular release schedule. After all, we already had 3 months to add code to Zope 2 and Zope 3 trunk that will be included in the next release, as I believe they branched at the time. Could you explain the reasons for the coming 3 months being too short in this particular case? What features are we adding to Zope 2 or Zope 3 that make it too short and thus would result in a not-solid-enough release? I think the egg-story is one candidate for being too big, and a possible reason to shift the release schedule. Then again, we do not need the egg story to land in the upcoming release anyway. Regards, Martijn
--On 12. September 2006 13:06:05 +0200 Martijn Faassen <faassen@infrae.com> wrote:
Andreas Jung wrote:
--On 12. September 2006 12:28:10 +0200 Martijn Faassen <faassen@infrae.com> wrote: [snip]
Anyway, if the main thing holding up *this* release is bugfixes, doing a new release in 3 months shouldn't be a problem, as after all, we've already fixed those bugs this time around. :)
3 month for a new release cycle is just too short. We should not follow the IMO broken concept of "release early, release often" but to follow "release regular, release solid". At least me I refuse to release something just for the sake of making a release at a certain date.
The current CHANGES.txt from the trunk just lists one new feature (added by myself). That's does not deserve a major release.
The goal is not release early, release often, but to get back to our regular release schedule. After all, we already had 3 months to add code to Zope 2 and Zope 3 trunk that will be included in the next release, as I believe they branched at the time.
Not much happened during the three month or I did I miss something?
Could you explain the reasons for the coming 3 months being too short in this particular case? What features are we adding to Zope 2 or Zope 3 that make it too short and thus would result in a not-solid-enough release?
We just don't have nothing new right now. Another point with this whole half-yr release cycle: we're going to confuse more and more professional users about which Zope version to use for what. I've heard from my major customer but also from other ppl. IN December we would have *three* maintained versions 2.9, 2.10 and 2.11. We definitely can't deprecate Zope 2.9 in December because this version is required by Plone 2.5. Plone 2.5 was just released and ppl just start to migrate from Plone 2.1 to Plone 2.5. We have the burden maintain Zope 2.9 for the mid-future. So my personal impression right now is: we're flooding the community with new major releases and the community does not adapt those releases. My theory: a major part of the ppl running Zope are running Plone. on top of Zope...so with have to deal with this fact somehow. Andreas
I think the egg-story is one candidate for being too big, and a possible reason to shift the release schedule. Then again, we do not need the egg story to land in the upcoming release anyway.
Regards,
Martijn
-- ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: info@zopyx.com - Phone +49 - 7071 - 793376 E-Publishing, Python, Zope & Plone development, Consulting
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12 Sep 2006, at 13:19, Andreas Jung wrote:
Another point with this whole half-yr release cycle: we're going to confuse more and more professional users about which Zope version to use for what. I've heard from my major customer but also from other ppl. IN December we would have *three* maintained versions 2.9, 2.10 and 2.11. We definitely can't deprecate Zope 2.9 in December because this version is required by Plone 2.5. Plone 2.5 was just released and ppl just start to migrate from Plone 2.1 to Plone 2.5. We have the burden maintain Zope 2.9 for the mid-future. So my personal impression right now is: we're flooding the community with new major releases and the community does not adapt those releases. My theory: a major part of the ppl running Zope are running Plone. on top of Zope...so with have to deal with this fact somehow.
Speaking just for the Zope 2 side: It's not just Plone users that get left behind. IMHO that half year cycle should be revisited. I strongly believe it is too short. We're overburdening the community/ customers with a slew of major releases at this point. jens -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFFBp/XRAx5nvEhZLIRAoo/AJ9Ir94Gdg+8anUln/AVhrWcpGgH8ACdGsPe yNVMcC3L8oEeW2o6A3B/99I= =v1xG -----END PGP SIGNATURE-----
Andreas Jung wrote:
--On 12. September 2006 13:06:05 +0200 Martijn Faassen <faassen@infrae.com> wrote:
Andreas Jung wrote:
--On 12. September 2006 12:28:10 +0200 Martijn Faassen <faassen@infrae.com> wrote: [snip]
Anyway, if the main thing holding up *this* release is bugfixes, doing a new release in 3 months shouldn't be a problem, as after all, we've already fixed those bugs this time around. :)
3 month for a new release cycle is just too short. We should not follow the IMO broken concept of "release early, release often" but to follow "release regular, release solid". At least me I refuse to release something just for the sake of making a release at a certain date.
The current CHANGES.txt from the trunk just lists one new feature (added by myself). That's does not deserve a major release.
It's the nature of time-based releases, though. If nobody does anything in 6 months, does that mean we won't have a release at all? Zope 2 also includes Zope 3, so that might help feature-wise.
The goal is not release early, release often, but to get back to our regular release schedule. After all, we already had 3 months to add code to Zope 2 and Zope 3 trunk that will be included in the next release, as I believe they branched at the time.
Not much happened during the three month or I did I miss something?
So imagine we had done the release in june as we planned and everything else would be the same. Would that mean we would've canceled the next release, as we'd only have 1 new feature?
Could you explain the reasons for the coming 3 months being too short in this particular case? What features are we adding to Zope 2 or Zope 3 that make it too short and thus would result in a not-solid-enough release?
We just don't have nothing new right now.
That could then not be affecting the solidity of the release, just how interesting the release is. :)
Another point with this whole half-yr release cycle: we're going to confuse more and more professional users about which Zope version to use for what. I've heard from my major customer but also from other ppl. IN December we would have *three* maintained versions 2.9, 2.10 and 2.11. We definitely can't deprecate Zope 2.9 in December because this version is required by Plone 2.5. Plone 2.5 was just released and ppl just start to migrate from Plone 2.1 to Plone 2.5. We have the burden maintain Zope 2.9 for the mid-future. So my personal impression right now is: we're flooding the community with new major releases and the community does not adapt those releases. My theory: a major part of the ppl running Zope are running Plone. on top of Zope...so with have to deal with this fact somehow.
That is a good argument for lengthening the release cycle. (as opposed to say, people will fix more bugs if the release cycle is longer) What do you think about a 9 month release cycle? Regards, Martijn
Hi. Martijn Faassen wrote:
Andreas Jung wrote:
--On 12. September 2006 13:06:05 +0200 Martijn Faassen <faassen@infrae.com> wrote:
Another point with this whole half-yr release cycle: we're going to confuse more and more professional users about which Zope version to use for what. I've heard from my major customer but also from other ppl. IN December we would have *three* maintained versions 2.9, 2.10 and 2.11. We definitely can't deprecate Zope 2.9 in December because this version is required by Plone 2.5. Plone 2.5 was just released and ppl just start to migrate from Plone 2.1 to Plone 2.5. We have the burden maintain Zope 2.9 for the mid-future. So my personal impression right now is: we're flooding the community with new major releases and the community does not adapt those releases. My theory: a major part of the ppl running Zope are running Plone. on top of Zope...so with have to deal with this fact somehow.
As Plone was mentioned as a an argument for scheduling releases, I should probably explain our current release strategy. Similar to Zope 2.8 we had a Plone 2.1 release that took more than 18 months to complete. After that we aimed for the next release (called 2.5) to ship six month after that. Here we tried to copy the new Zope release schedule. But while we tried hard to get a release out in time, we did not succeed with it and ended up with a 9 month release cycle. Now we again aimed for a release six month after 2.5 but we had to adjust our roadmap already and right now we aim for another 9 month release cycle.
That is a good argument for lengthening the release cycle. (as opposed to say, people will fix more bugs if the release cycle is longer)
What do you think about a 9 month release cycle?
Based on the Plone experience I think this is a good compromise, between release often and stable releases. Hanno
Martijn Faassen wrote:
Andreas Jung wrote:
Another point with this whole half-yr release cycle: we're going to confuse more and more professional users about which Zope version to use for what. I've heard from my major customer but also from other ppl. IN December we would have *three* maintained versions 2.9, 2.10 and 2.11. We definitely can't deprecate Zope 2.9 in December because this version is required by Plone 2.5. Plone 2.5 was just released and ppl just start to migrate from Plone 2.1 to Plone 2.5. We have the burden maintain Zope 2.9 for the mid-future. So my personal impression right now is: we're flooding the community with new major releases and the community does not adapt those releases. My theory: a major part of the ppl running Zope are running Plone. on top of Zope...so with have to deal with this fact somehow.
That is a good argument for lengthening the release cycle. (as opposed to say, people will fix more bugs if the release cycle is longer)
What do you think about a 9 month release cycle?
If we can't manage a 6 month cycle, 9 months is the longest release cycle I think is acceptable. Personally I think we should just release the trunk every six months (with a list of known bugs) and that be it. (I'm speaking of Zope 3 here, I don't know enough about the dynamics of the Zope 2 ecosystem to comment there.) -- Benji York Senior Software Engineer Zope Corporation
Benji York wrote:
Martijn Faassen wrote: [snip]
What do you think about a 9 month release cycle?
If we can't manage a 6 month cycle, 9 months is the longest release cycle I think is acceptable.
Agreed. I'd like to avoid longer than 9 months too.
Personally I think we should just release the trunk every six months (with a list of known bugs) and that be it. (I'm speaking of Zope 3 here, I don't know enough about the dynamics of the Zope 2 ecosystem to comment there.)
I think that this is an edge case of time-based releasing: the absolute minimal work we need to do to make a time-based release is to release the trunk. Hopefully we'll be doing more than the minimal amount of work, and we'll actually fix some bugs before we release the trunk. A release can be a good opportunity to fix lingering bugs, after all. Of course with eggification of Zope 3, 'releasing the trunk' is going to be less meaningful in the future... Regards, Martijn
--On 12. September 2006 16:55:31 +0200 Martijn Faassen <faassen@infrae.com> wrote:
Personally I think we should just release the trunk every six months (with a list of known bugs) and that be it. (I'm speaking of Zope 3 here, I don't know enough about the dynamics of the Zope 2 ecosystem to comment there.)
I think that this is an edge case of time-based releasing: the absolute minimal work we need to do to make a time-based release is to release the trunk. Hopefully we'll be doing more than the minimal amount of work, and we'll actually fix some bugs before we release the trunk. A release can be a good opportunity to fix lingering bugs, after all.
I am thinking since one hour about how to reply to Benji's proposal. It's not much acceptable. Major release have to be planned to a certain degree and must be tested (as good as we can) - means we must have alpha and beta releases. Everything else does not make sense to me. Zope 2 is not a kindergarten project and we use it for professional projects and we as a community should act (somewhat) professional. You can of course make daily snapshots available but most developers are using SVN checkouts and professional users don't want depend on snapshots - they expect official releases. Andreas
Andreas Jung wrote:
I am thinking since one hour about how to reply to Benji's proposal. It's not much acceptable. Major release have to be planned to a certain degree and must be tested (as good as we can) - means we must have alpha and beta releases.
I wasn't proposing we do away with alphas or betas. More concretely: I was simply wondering aloud about doing "true" time-based releases. On a certain date we cut the first alpha, on a certain date we cut the first beta, etc.. Of course, there must be /some/ flexibility to deal with ultra-critical bugs, but we already do something similar with how we treat release candidates. I believe that the trunk is good enough to produce a release at (almost) any given time. If bugs are known and unfixed when we do a release, we document them (they likely already exist in the previous released version, so we're not doing any harm there). Again, this is all from my Zope 3 perspective, I'm not immersed in the Zope 2 world, so these ideas may not be applicable there. -- Benji York Senior Software Engineer Zope Corporation
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12 Sep 2006, at 14:44, Martijn Faassen wrote:
Another point with this whole half-yr release cycle: we're going to confuse more and more professional users about which Zope version to use for what. I've heard from my major customer but also from other ppl. IN December we would have *three* maintained versions 2.9, 2.10 and 2.11. We definitely can't deprecate Zope 2.9 in December because this version is required by Plone 2.5. Plone 2.5 was just released and ppl just start to migrate from Plone 2.1 to Plone 2.5. We have the burden maintain Zope 2.9 for the mid-future. So my personal impression right now is: we're flooding the community with new major releases and the community does not adapt those releases. My theory: a major part of the ppl running Zope are running Plone. on top of Zope...so with have to deal with this fact somehow.
That is a good argument for lengthening the release cycle. (as opposed to say, people will fix more bugs if the release cycle is longer)
What do you think about a 9 month release cycle?
+1 from me jens -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFFBsQORAx5nvEhZLIRAgCTAKCuhBwuh8/c1vUhUORRHDUidbRc3gCeOZFs 3cYCUp61vudMo9cIJACJtdY= =EbCV -----END PGP SIGNATURE-----
Martijn Faassen wrote at 2006-9-12 14:44 +0200:
...
The current CHANGES.txt from the trunk just lists one new feature (added by myself). That's does not deserve a major release.
It's the nature of time-based releases, though. If nobody does anything in 6 months, does that mean we won't have a release at all?
Of course! Why in hell should you make a release with nothing relevant in it? Both the release process are well as the upgrade process entail a considerable amount of work. You do it only if it is worth the effort. -- Dieter
On Sep 12, 2006, at 5:47 AM, Andreas Jung wrote:
Hi all,
since we are three month late with the current releas, it would make sense to reschedule Zope 2.11/3.4 for July (or was it June) next yr?! If we want to stick with the half-yr cycles, we need to schedule the next release for around March/April next yr. Thoughts?
We were hoping two switch to May and November. I'd be for May for 2.11/3.4. 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 Tuesday 12 September 2006 07:56, Jim Fulton wrote:
On Sep 12, 2006, at 5:47 AM, Andreas Jung wrote:
Hi all,
since we are three month late with the current releas, it would make sense to reschedule Zope 2.11/3.4 for July (or was it June) next yr?! If we want to stick with the half-yr cycles, we need to schedule the next release for around March/April next yr. Thoughts?
We were hoping two switch to May and November. I'd be for May for 2.11/3.4.
+1 Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training
participants (8)
-
Andreas Jung -
Benji York -
Dieter Maurer -
Hanno Schlichting -
Jens Vagelpohl -
Jim Fulton -
Martijn Faassen -
Stephan Richter