101–110 of 195 posts
I've always wondered this: why release on a schedule at all? If people demand a certain new feature ("[this will] bring you new features more quickly"), it can just be brought out as it's ready, instead of having to wait an average of 3 (now 2) weeks before it can be released? And why does this have to increment the major version, since when is every single update backwards incompatible?
Earlier quoted context omitted.
Quality can be worse in a long-time cycle project: - Engineers are motivated to slam their feature in, because if they miss the train the next one's not for 12 months. - You get one moment per year to connect with your customers & understand how well/not well your changes worked. This means either riskier things happen or that innovation slows to a crawl. My 2 cents, speaking from some experience working on long time…
Why cycles at all? Why not look at what features have been integrated, whether they make up a set that you want to release, and then release? Neither long cycles nor short cycles make any sense. Some features take a long time to develop, some take a short time to develop. Sometimes features that take a long time to develop aren't user-facing enough to be worth releasing for, and sometimes a quick fix has a huge impac…
I imagine that could work well in some cases, but it also allows corporate bureaucracy and/or marketing teams to determine when things get released at larger scales and that might not be so ideal.
Earlier quoted context omitted.
Quality can be worse in a long-time cycle project: - Engineers are motivated to slam their feature in, because if they miss the train the next one's not for 12 months. - You get one moment per year to connect with your customers & understand how well/not well your changes worked. This means either riskier things happen or that innovation slows to a crawl. My 2 cents, speaking from some experience working on long time…
Why cycles at all? Why not look at what features have been integrated, whether they make up a set that you want to release, and then release? Neither long cycles nor short cycles make any sense. Some features take a long time to develop, some take a short time to develop. Sometimes features that take a long time to develop aren't user-facing enough to be worth releasing for, and sometimes a quick fix has a huge impac…
There's an incidental benefit here. There's at least one system (I think Duo + Okta?) which, when configured to check if your browser is out of date, makes a logic error. It should check if your browser is the most recent, and, if it isn't, if the _new release_ is over N days old. Instead, it checks if your browser is the most recent, and if it isn't, if the _old release_ is over N days old. So, if you run Firefox an…
There's an incidental benefit here. There's at least one system (I think Duo + Okta?) which, when configured to check if your browser is out of date, makes a logic error. It should check if your browser is the most recent, and, if it isn't, if the _new release_ is over N days old. Instead, it checks if your browser is the most recent, and if it isn't, if the _old release_ is over N days old. So, if you run Firefox an…
It's Duo that has the "Software Update Notification" feature ( https://guide.duo.com/software-update ). If more vendors go the direction of faster updates, that feature on Duo (and I'm sure others) will need to be tweaked heavily.
I don't know if 4 weeks is or isn't the right answer (after all some SaaS companies update dozens of times a day), but I know that I tend to leave my browser windows open until it crashes or the computer reboots. While I don't regularly use Firefox right now, I can imagine that I could skip entire versions with this behavior.
Earlier quoted context omitted.
Quality can be worse in a long-time cycle project: - Engineers are motivated to slam their feature in, because if they miss the train the next one's not for 12 months. - You get one moment per year to connect with your customers & understand how well/not well your changes worked. This means either riskier things happen or that innovation slows to a crawl. My 2 cents, speaking from some experience working on long time…
Why cycles at all? Why not look at what features have been integrated, whether they make up a set that you want to release, and then release? Neither long cycles nor short cycles make any sense. Some features take a long time to develop, some take a short time to develop. Sometimes features that take a long time to develop aren't user-facing enough to be worth releasing for, and sometimes a quick fix has a huge impac…
It depends on the project, but in larger projects the calendar approach means politics takes a back seat as no one can hold back the release if their feature hasn't been merged yet due to blocking issues. And it helps keep the change-set small, and hence lower risk, if you release more often.
Also, Firefox already has a nightly release stream. I use the Aurora stream which releases a few times a week and have almost never had an issue with this frequency. I don't think a monthly release cycle is going to be an issue.
Earlier quoted context omitted.
Semantic versioning is useful for libraries. Let useful for consumer apps. 2019-10 says more than 76.0.0
> 2019-10 says more than 76.0.0 Neither says anything useful . 2019-10 is no more actionable or informative than 76.0.0. That 2019-10 was released in october 2019 is meaningless information and only "more" in the "babble" sense.
The thing that scares me about this change is that it seems like the only reason they are doing it is "we’ve had many requests to take features to market sooner.". Where as the rest of the blog entry is to assuage our fears and otherwise placate everyone that things won't explode. I don't know if 4 weeks is or isn't the right answer (after all some SaaS companies update dozens of times a day), but I know that I tend…