As things seem to be settled down with the completion of the Github → Discourse migration, I was wondering if there are plans for a regular release cadence – monthly/bi-monthly/etc. It would be really helpful as a user to know when to expect things on Master to make it into a release build.
Thanks for all the hard work getting here to @bengotow @CodeMouse92 @Phylu and others.
Although Ben can probably answer the question better than I, based on planning conversations, there is no real way to commit to a release cadence given that everyone, even Ben, does this on the side.
Take a look at #roadmap, particularly About Bundles on that category, to learn more.
Totally get the side-project challenges, and I know many open source projects prefer a “when it’s done” approach to a regular release model.
On the flip side, I think regular releases are actually great for projects that get irregular code contributions. As long as Master always builds, it helps get smaller updates out the door faster. Rather than waiting on Bundle X to be done, the Unsubscribe work or the Typescript improvements get shipped at release interval N.
Happy to continue paying and using either way, but that’s my 2¢.
Oh, I understand, but it’s also not fair to developers or users to have an arbitrary timeframe for releases when it’s impossible to predict when there will be sufficient development time to create said release. The Bundles concept is new to the project, specifically because until this point, Mailspring has tried to fit into a traditional release concept, and it hasn’t worked well.
Fair! I think my mindset is that a small release, automatically cut from master, with one commit is better than 30 commits to master that may not see a release for an unknown period of time, but there’s no one right way to run a project, and this one isn’t mine to run 
I suppose I can always build locally if there’s something critical for me, and others can make the same call.