branan

My interpretation of "weeks, not months" was always "it'll make sense to think in terms of weeks instead of months". It's only beyond about 10 weeks where talking about months makes sense. I come from an engineering background where communicating about schedules in weeks is pretty normal, but I don't think that it's an unusual way of speaking. Going down the scale, lots of people would say "10 days" or even "15 days" before just rounding to weeks. And up the scale, people talk about the age of babies in months up until almost 30, in my experience.

As long as we're still in "weeks, not months" (so maybe every six-eight weeks), I'll be happy. I think that's realistic, but of course I'm not directly familiar with the dev process for this game. Lots of folks on this forum have given input based on their experience as developers. But I will say, specific to this communication: It's a huge investment to pivot a software engineering team towards being able to ship smaller changes more frequently. My impression is that the team has been shipping more quickly than they're necessarily comfortable with, because the fixes are small/focused changes. Now that they want to focus more on bigger features (and bigger bugfixes, which IME are more like features than fixes), they don't know how to break down that work into small enough chunks to ship quite as often. I personally hope that over the course of early access the devs do spend some time adjusting their processes and workflows to enable shipping more often. But those changes need to be balanced with getting stuff out the door. Imagine how mad everyone would be if we got a blog post saying "we're not going to ship for a quarter so that we can figure out how to ship faster"