3 ms·

Good point, but factor in build/release, then deployment. We all know what some companies are like in their desktop real estate rollouts - if you have too freq

by Zenst 7y ago

Good point, but factor in build/release, then deployment. We all know what some companies are like in their desktop real estate rollouts - if you have too frequent updates, you end up with greater disparity in releases with a template support of - oh that's not the latest, pls try again. Then feedback, if you rollout release too frequently you also can be several releases in and get feedback of some bug in a release prior to current release, albeit only a week or so. So by having organised releases, allows better management and a better experience overall. It's a fine balance, but for those who needs it, there will always be nightly builds of most things they want with last second updates, also self-builds for those inclined. But I get the whole artificial timeframe does seem somewhat odd, but the further you look at the overall usage, management and support factors et all, you start to appreciate such regular timeframes. On the other extreme, I've worked in an environment in which a whole suit had to be retested and go thru all the hopes as a full stop was missed of a comment and that change caused the whole testing, management/release cycle to go thru the motions again. That you would like, ignore and package up with other small things into a full release - which is what many do these days in most environments. After all - would you want to go thru a rollout of a new release that may contain a fix you want, or equally may just be adding a full stop to a comment in the code and yielding no binary level changes, albeit that it went thru the whole hoops and hurdles as a full release and that is what you got. So from my experience, a 4 week release cycle is good, fixed, something that you can plan around. Also kudos for not just picking a day a month and doing monthly updates like most, that tends to seem more arbitrary unlike 4 weeks, which has an air of less arbitrary and feels like it was thought out more. Though an element of personal experience does come into play.

cpeterso 7y ago
> kudos for not just picking a day a month and doing monthly updates like most, that tends to seem more arbitrary unlike 4 weeks Planning feature development and rollout is more difficult if you always have to refer to a calendar to find future release dates. I would prefer to be able to say a feature can land in Firefox Nightly in January, ship to Firefox Beta on February 1, and Release channel users on March 1. Mozilla has a long wiki page of past and future release dates: https://wiki.mozilla.org/RapidRelease/Calendar https://wiki.mozilla.org/RapidRelease/Calendar
- re4ctor 7y ago
  The problem there is February 1st isn't always a good release day, say if it's a Saturday. So you'd ship on the 2nd or 3rd sometimes... or sometimes that's a holiday, or there are validate reasons to avoid a period (like the first ~week of July or September). You could try to pick something like the "2nd Wednesday" of the month, but there are still occasions for mid-week holidays and other timing problems related to marketing or external events (other announcements, or world events that would clobber your marketing push). Inevitably you have to plan it anyway, so you might as well do that from the start.

by Zenst 7y ago

cpeterso 7y ago

> kudos for not just picking a day a month and doing monthly updates like most, that tends to seem more arbitrary unlike 4 weeks Planning feature development and rollout is more difficult if you always have to refer to a calendar to find future release dates. I would prefer to be able to say a feature can land in Firefox Nightly in January, ship to Firefox Beta on February 1, and Release channel users on March 1. Mozilla has a long wiki page of past and future release dates: https://wiki.mozilla.org/RapidRelease/Calendar https://wiki.mozilla.org/RapidRelease/Calendar

re4ctor 7y ago
The problem there is February 1st isn't always a good release day, say if it's a Saturday. So you'd ship on the 2nd or 3rd sometimes... or sometimes that's a holiday, or there are validate reasons to avoid a period (like the first ~week of July or September). You could try to pick something like the "2nd Wednesday" of the month, but there are still occasions for mid-week holidays and other timing problems related to marketing or external events (other announcements, or world events that would clobber your marketing push). Inevitably you have to plan it anyway, so you might as well do that from the start.