Consider releasing less often

[fzaninotto]

I know this package is all about detecting changes in dependencies, but your release process makes it nearly impossible to determine when a feature was released, or which features I can gain from a version bump...

[rarkins]

Right now I am a recent convert to the semantic release approach to "unromantic and unsentimental" releases. As part of this you'll find features in x.y.0 releases only, and everything else is a fix or refactor.

As part of semantic release, a new GitHub release is made for each version of renovate, you can see them here: https://github.com/singapore/renovate/releases

As far as I'm aware, most people use the tool one of two ways:

1. Use the GitHub App where I push each new release almost immediately so I can detect any breaks and roll back or fix
2. On their own automated system like CI, where they just npm i -g renovate or perhaps tie to a version (e.g. npm i -g renovate@9) and trust I don't break or fix breaks fast enough

You could also consider using a tool like changelog to provide a list of changes between certain releases.

If these don't really satisfy, could you describe in more detail about how you "decide" when to update?

[fzaninotto]

Well, first of all, each update in a package I depend on means unplanned work. So a package releasing too often has a signal/noise ratio too low, and I would probably completely silence the releases for it - possibly missing important updates in the process.

Second, when I decide to upgrade a package, I need a list of all the things that change so that I understand what I need to do in my codebase. Yes, the changelog tool you mention can do that, but IMHO it's the package author's job to provide it, not the user.

Lastly, a package released several times a day feels like it's using developers as beta testers. IMO it's a proof of quality to release only battle-tested releases.

[rarkins]

I think every point you have (or counterpoint I could respond with) still comes back to the same fundamental disagreement: you don't like the "semantic release" approach to software versioning. Otherwise the only way to satisfy your impression of "quality" while maintaining semantic releasing would be to just release features less often, which obviously isn't your goal.

With the current approach to releases, I'd suggest either:

1. If using the service, trust the service and ignore the source. For example your hosted CI service could be using semantic versioning internally and pushing to production 5x per day for all you know - the only difference is they're not exposing those release numbers or notes like here.

2. If running it yourself, perhaps you can add renovate with a pinned version to a package.json and then renovate that repository itself on a schedule such as once per week (see FAQ). You will then get a single page list of releases and their commits/feature notes since the current version you're running.

[rarkins]

I think I'll close this issue for now because it really translates to "Don't use semantic release" and for now I will be sticking to it. Happy to receive more comments here in the meantime.

[rarkins]

@fzaninotto out of curiosity, would it be useful if renovate had a "baked in" way to check for updates? e.g. if you ran your installed version of renovate with a new flag like renovate --check-for-updates or something like that and it printed to console what the latest renovate version is and a summary of every feature and fix since the installed release?

[fzaninotto]

Thanks for your explanations, they make sense, even if we disagree.

As for renovate --check-for-updates, it wouldn't work for people like me who use the GitHub App. For us, the gitHub Releases page is the only point of information about possible BC breaks in the configuration syntax, new features, etc.

[rarkins]

I intend to stick to semver syntax pretty strictly, i.e. renovate@9 should not break any configuration syntax. But as an App user, what prevents me from releasing renovate@10 and pushing it live, possibly messing up your configuration?

My plan is this:

1. If the need for non-backwards compatible configuration change is necessary or highly desirable, I will support both in renovate@9 at first.
2. I will add a feature to renovate@9 to raise a "Migrate config" PR to detect "old" style configuration in repositories and update that to the new style to retain the same behaviour. This PR should specify once there is any cut-off date for migrating.
3. Only update to renovate@10 in the GitHub App once the logs indicate it's ready to do so. Renovate@10 will remove support for any "old" configuration styles

[hutson]

I will add a feature to renovate@9 to raise a "Migrate config" PR to detect "old" style configuration in repositories and update that to the new style to retain the same behaviour.

That would be really appreciated. I recently enabled the GitHub App for a project, and my only concern was whether there was a mechanism for informing me of breaking changes to configuration or features.

I guess in the case of a feature getting removed, could you just remove the configuration from the renovate config?

[rarkins]

I guess in the case of a feature getting removed, could you just remove the configuration from the renovate config?

Hard to predict - configuration might get completely removed, or it might have its structure modified, or maybe just get a different default. Whatever is the case, the script should take the old config and transform it to new, whatever that takes.