Hi all! I want to bring up this discussion because we are approaching the date when there would be a feature freeze following the time based release schedule.
To make it short, I would suggest to not follow the time-based schedule for that release. There are a bunch of reasons bringing me to that view: - 1.3.0, which was very much pushed by the time-based schedule was not the best release we ever made. In fact, it had quite a few open issues that required an immediate 1.3.1 followup and only 1.3.2 fixed some of them. - 1.3.2, which is in some sense what 1.3.0 should have been is only 2 weeks back - The delta since the last release is still quite small. One could argue to make a quick release and then soon another release after that, but releases still tie up quite a good amount of resources, so that would introduce a delay for much of the ongoing work. I am doubtful if this is a good idea at this point. - The current master has still quite a bit of "ongoing work" that is not in perfect shape for a release, but could use some more weeks to provide real value to users. Examples are the dependency reworking, network stack enhancements, speedier state restore efforts, flip-6, exactly-once sinks/side-effects, and others. Alternatively, we could do what we did for 1.1 and 1.2, which is making now a list of features we want in the release, and then projecting based on that when we fork off the 1.4 release branch. What do you think? Cheers, Stephan
