On Mon, Jun 25, 2018 at 8:40 PM Chase Peeler <chasepee...@gmail.com> wrote:
> 1.) Old code breaks during minor updates. We upgraded to 7.0 AFTER 7.1 was > released, because we had already made major updates to upgrade to 7.0, and > 7.1 introduced a few things that would have broken our code - we didn't > have time to fix those by that point. "Throw on passing too few function > arguments" would actually break more stuff in our legacy code than all of > the 7.0 changes combined. > I agree. It was a bad decision on our part to do it in 7.1 - this bit a lot of users. > Finally, I personally see the idea of a deprecation only release to be kind > of silly. I don't work for a software company. It's tough enough for me to > make a case for upgrading using the "increase performance" and "new > features" argument. There is no way I'd get the go-ahead to do an upgrade > that would just make additional features deprecated. It would be a better > use of my time to look for and fix the deprecated features as part of the > 8.0 upgrade prep, than to upgrade to 7.4. Maybe look at at backporting some > of the new 8.0 features that aren't really dependent on the major things > like JIT, async, etc., as part of the 7.4 release. > > Fair enough, and I think there'll likely be a lot of folks that would see no point in going through such a 7.4. However, I think that folks working in more agile companies, or even developers that want to get a head start on preparing for 8.0 - will find value in such a release. TBH, the vast majority of users don't upgrade to our minor versions even when they bring new features and capabilities. Zeev
