Re: [Zope3-dev] Re: [Zope-dev] Release schedule for Zope 2.11/3.4?
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 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Zope-dev] Release schedule for Zope 2.11/3.4?
Benji York 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.) What good could that possibly do? For the people who are not spending their days reading checkin messages, something that is called a final release is a promise that the features they get have been tested and are considered stable, that they can rely on a certain degree of backwards compatibility, and that they're going to get burned. Releases are externally-facing things. They benefit people other than the core contributors the most (the core contributors mostly get the gratification of having released something, and then probably go on playing with trunk). The quality those people receive must be the most important factor by which a release is judged. .0 releases of Zope (2) have had a somewhat negative image before (to the point where people were afraid to let Plone depend on a Zope release that didn't have a .1 or .2 release out already), which I think is getting better. Undoing that would be to the detriment of how people perceive the quality of our software. By the same token, we could just never have releases and expect everyone to live off svn trunk. The idea of a release *cycle* is surely that it's cyclical: at the beginning, we worry about features and innovation, at the end we worry about stability and polish. If the timelines are worked out correctly, then time-based releases help us manage scope and keep moving at a pace that doesn't mean we have enormous mountains of features that take an infinite amount of time to stabilise and get ready. That's a good thing, but ignoring the end-result quality argument by being slaves to the Great Roadmap that was set out six months ago isn't. It's very waterfall. :) Martin (pardon any hyperbole) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Zope-dev] Release schedule for Zope 2.11/3.4?
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 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Zope-dev] Release schedule for Zope 2.11/3.4?
--On 12. September 2006 16:55:31 +0200 Martijn Faassen <[EMAIL PROTECTED]> 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 pgp0MBvxjRcPa.pgp Description: PGP signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Zope-dev] Release schedule for Zope 2.11/3.4?
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 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Zope-dev] Release schedule for Zope 2.11/3.4?
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 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Zope-dev] Release schedule for Zope 2.11/3.4?
Andreas Jung wrote: --On 12. September 2006 13:06:05 +0200 Martijn Faassen <[EMAIL PROTECTED]> wrote: Andreas Jung wrote: --On 12. September 2006 12:28:10 +0200 Martijn Faassen <[EMAIL PROTECTED]> 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 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Zope-dev] Release schedule for Zope 2.11/3.4?
--On 12. September 2006 13:06:05 +0200 Martijn Faassen <[EMAIL PROTECTED]> wrote: Andreas Jung wrote: --On 12. September 2006 12:28:10 +0200 Martijn Faassen <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] - Phone +49 - 7071 - 793376 E-Publishing, Python, Zope & Plone development, Consulting pgpKzG0VOomAk.pgp Description: PGP signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Zope-dev] Release schedule for Zope 2.11/3.4?
Andreas Jung wrote: --On 12. September 2006 12:28:10 +0200 Martijn Faassen <[EMAIL PROTECTED]> 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 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Zope-dev] Release schedule for Zope 2.11/3.4?
--On 12. September 2006 12:28:10 +0200 Martijn Faassen <[EMAIL PROTECTED]> 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 pgpSiZKwtHn0V.pgp Description: PGP signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Zope-dev] Release schedule for Zope 2.11/3.4?
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 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
