feat: allow prerelease releases on Github

[kalosisz]

Thank you for opening a Pull Request! Before submitting your PR, there are a few things you can do to make sure it goes smoothly:

• Make sure to open an issue as a bug/issue before writing your code! That way we can discuss the change, evaluate designs, and agree on the general idea
• Ensure the tests and linter pass
• Code coverage does not decrease (if any source code was changed)
• Appropriate docs were updated (if necessary)

Fixes #1180 🦕

[bcoe]

Thank you for the PR @kalosisz 👏 might take a few days to review due to NY but excited for this.

[chingor13]

Thanks and this is looking great!

If I'm reading this right, it's not affecting the commits we consider since the last release. Are you intending to use this on a separate release branch? If not, when it comes time to release a stable version, it won't grab all the commits since the last stable version - it will grab since last release of any type on the release branch. (FWIW, we are probably going to be maintaining a preview branch in the near future which runs in parallel to the main branch and would probably use this --prerelease option).

[kalosisz]

@chingor13 you are right. it would always consider the last release if it's not releaseing from a different branch.

I think it would be nice if one could specify to only consider stable releases (only storing those in the manifest.json or when looking for the latest release) as well. I could add such a feature if one's using the --prerelease option. I am a bit unsure of the builds though. Should they be considered stable?

[kalosisz]

hey @chingor13. I was thinking on having to generate the release notes on a prerelease from a stable. I reckon the library could have another flag for that for if one has a preview branch and only want to create release notes between prereleases, it
wouldn't be possible. I would leave this prerelese flag as it is now, to only create a Github prerelease.

What do you think?

[ChipWolf]

How would prerelease versioning work?

[kalosisz]

Versionings are managed in strategies and versioning-strategies. They might need to be extended.

Check out

release-please/src/strategies/base.ts

Lines 102 to 103 in a7977bc

	this.versioningStrategy =
	options.versioningStrategy || new DefaultVersioningStrategy({});

[chingor13]

I might be ok with having it always create the release as prerelease on GitHub. A repo maintainer may want to turn on that flag for pre-1.0.0 versions.

[kalosisz]

@chingor13 So far I was looking only at the prerelease part, but based on your last comment, I added releasing pre-major as prereleaes in 6f3b7e5

I see my new commits didn't remove your approval? Is this intentional?