Formalize major releases policy

[alberto]

Background

In line with #6244 and #5845, I'd like to discuss the merits of having a more predictable major release policy.

Problems

Breaking changes cause disruption to end users. Shared configs tend to depend on a specific major version (e.g. airbnb, standard), so after every major release there is a period where these won't work.

Proposal

Nothing very concrete here, I would like to hear some opinions. I think having no more than one or two majors per year is a good middle ground. I'm not sure if having some predefined release schedule, similar to those of node or ubuntu would be an improvement.

[nzakas]

Hmm, there's not a lot to go on here. We have generally just done major releases when we have breaking changes to make (AFAIK, Node does the same). We always announce breaking releases ahead of time to give dependencies a warning.

I guess I'm just not sure what problem we are trying to solve here. Breaking changes are expected to break things, and we give fair warning already. Is there another concern? Or a concrete proposal about a different way of doing things?

[alberto]

I'm trying to see if we could reduce the friction with major releases somehow. Plugin compatibility is probably the biggest one, as evidenced in #6617.

PS: Node has a predictable release schedule now: https://github.com/nodejs/LTS

[nzakas]

@alberto Again, this really isn't enough information to work on. Plugins, shared configs, etc., will always break when we do a major release until they are updated. The best we can do is give people fair warning when a new major version is released (which we do).

I'm not sure that moving to a periodic rather than feature-based major version makes much sense for us. Periodically incrementing the major version number without a breaking change would be confusing to users, and needing to wait an extra amount of time to release important breaking changes doesn't seem like a good idea either.

I understand that you want to help reduce friction of major releases, and that's a great goal. There's just not enough information in this issue to have a good discussion (I'm guessing that's why we haven't seen any other comments on this thread). If you want to continue to pursue this, I'd suggest you more clearly define what "friction" means, breaking that out into a list of problems you're seeing, and then suggesting what might change to solve those problems.

FWIW, I think the automated regression testing that @ilyavolodin is working on will be helpful in giving us at least a heads up as to what might break.

[alberto]

I don't have anything more concrete than that. Having a fixed schedule was just a possibility I was throwing. I opened the issue to see if someone had any ideas or opinions on how to articulate this. Since this doesn't seem to be the case, we can close it.