Moshe Weitzman wrote:
1) Your target audience is very very small. Comparatively, only a handfull of developers will be using HEAD, and they'll be developing with it, not using contrib modules.
Why bother convincing Contrib maintainers that tracking core HEAD is a bad idea? If you don't like it, don't do it.
There is a disconnect between: We recommend you do this (Dries' position recommending A) and If you don't like it, don't do it.
Some people actually do track HEAD and I am very thankful for them. In particular, these people actually use the APIs that are being dreamed up in HEAD. This fixes bugs and refines APIs *before* the code freeze. For example, og converted to using the node arbitrator stuff during the release cycle and as a result a few improvements were made before freeze.
This isn't how I feel most contrib authors are likely to operate. Contrib authors who are very close to core and interact regularly with the core developers and have a good feel for the patches that are going in can do this. But I think it's unrealistic to recommend that most contrib developers do this. And there are some cases like the node_access stuff where we do need modules to actually utilize the API, but bear in mind the burden that puts on the module developer. Also, what you describe isn't *actually* option a. Option a suggests you have basically stopped development on the previous version of the module before the next version of Drupal is even available. It's *this* that I'm arguing against. That is a bad practice that, in the 4.7 cycle, left a lot of people in a limbo of seeing new features that they couldn't use.