Reconsider default of daily dependency upgrade workflow scheduling

[echeung-amzn]

By default, JavaScript projects:

• Run a workflow to upgrade dependencies daily
• Publish libraries on pushes to the main branch

This combination seems to be creating huge amounts of releases across most projects using projen that haven't touched these defaults, and seems quite wasteful considering:

• The only difference in many of these published versions are typically just some minor/patch version dependency bumps that bring no significant value to library consumers
• The wasted storage for all of these insignificant versions
• The sheer amount of energy being used to run these workflows
• Ends up making the commit log and releases hard to grok through to find actual noteworthy changes

Should we consider instead defaulting to a less frequent cadence (e.g. weekly), or maybe even some of the changes applied in #3041?

[mrgrain]

I'm very sympathetic to this, I'm just not sure what the right way of resolving this is.

• Updating dependency daily seems important to me from the standpoint that this mechanism provides an alternative to tools like Dependabot. It also provides a clear upgrade path for projen inside these projects.
• Releasing on every commit is an implementation of Continuous delivery. Which seems maybe a bit extreme, but not sure if there's a middle ground.

Realistic options I see:

• Disable releases by default, potentially force users to pick a release trigger. This might be okay since by default it only releases to GitHub anyway, which is kind of pointless
• Reduce default dependency upgrade frequency - to what?
• Make the default smarter and release only featuresAndFixes() and mark dependency upgrades as chore

What do you think?

[echeung-amzn]

Make the default smarter and release only featuresAndFixes() and mark dependency upgrades as chore

That seems fairly reasonable to me, so long as it's clearly documented. The potential downside is that something that doesn't get any features nor fixes for an extended period of time will never get a new release until then, but perhaps that's a non-issue given that would normally be the case sans-projen anyway.

Reduce default dependency upgrade frequency - to what?

I do still think weekly is probably sufficient. It's what I configured over in cdk-monitoring-constructs and even then I still find it relatively noisy.

[RomainMuller]

I would suggest:

• Update dependencies daily
• Release-on-push only if either:
  • The commit is NOT a simple dependency update
  • The commit somehow was tagged for immediate release (e.g: fixes CVE)
  • The last release was more than a week ago (configurable)

[RichiCoder1]

I'd also endorse releasing less/only as necessary. Projens defaults are very noisy to the point we opted back out of it for the 2-3 projects we use it on in favor of renovate & grouping. Also ends up wasting a decent bit of package space from constant releases that functionally are identical.

[mrgrain]

• The commit somehow was tagged for immediate release (e.g: fixes CVE)
• The last release was more than a week ago (configurable)

While I'm generally in favor of this idea, these two options unfortunately don't exist yet. So unless someone wants to commit of building them out, I am more keen to learn about the changes that we can make with the features we have today.

[nikovirtala]

I’d go with what @RomainMuller suggested on https://github.com/projen/projen/issues/3164#issuecomment-1863183965

If that’s not viable due to the required efforts, I’d choose a combination of the following two:

• Reduce default dependency upgrade frequency - to what?

Weekly.

• Make the default smarter and release only featuresAndFixes() and mark dependency upgrades as chore