mirror of
https://github.com/goreleaser/goreleaser.git
synced 2025-01-24 04:16:27 +02:00
144 lines
4.8 KiB
Markdown
144 lines
4.8 KiB
Markdown
---
|
|
date: 2023-09-27
|
|
slug: release-cadence
|
|
categories:
|
|
- announcements
|
|
authors:
|
|
- caarlos0
|
|
---
|
|
|
|
# Version strategy and release cadence: the future
|
|
|
|
A couple of weeks ago, I got a couple of complaints about the way GoReleaser
|
|
is being versioned - more precisely, the fact that deprecated options are
|
|
removed in **minor** instead of **major** versions.
|
|
|
|
Those complaints are valid, and today I'm announcing how I plan to move forward.
|
|
|
|
<!-- more -->
|
|
|
|
## History
|
|
|
|
Before we do that, I feel like I should explain how we got in this position
|
|
first.
|
|
|
|
GoReleaser was in a [0ver](https://0ver.org)[^joke] scheme for _almost 5 years_.
|
|
We had a whopping _468 `v0.x.x` releases_.
|
|
Let me repeat: **four hundred and sixty eight v zeroes**.
|
|
|
|
[^joke]: yes, I know this is kind of a joke.
|
|
|
|
In fact, `v1` was launched less than 2 years ago, in [November, 2022][v1].
|
|
|
|
Like many other things, the way we handle deprecations was from that time.
|
|
A time in which GoReleaser never had major releases, because there wasn't
|
|
one: we would add the deprecation notice to the
|
|
[deprecations page][deprecations] and warn about it in the release's output
|
|
if you use any of them, and, after roughly 6 months, remove the deprecated
|
|
option and move on with life.
|
|
|
|
[Breaking changes are allowed in v0][semver-si4], so, there were no broken
|
|
promises.
|
|
|
|
On the other hand, `v1` is a _major_ version, so it should not introduce
|
|
breaking changes.
|
|
|
|
In retrospect, my mistake was never stopping to think about it again after `v1`.
|
|
|
|
[semver-si4]: https://semver.org/#spec-item-4
|
|
|
|
## Going forward
|
|
|
|
Thankfully, I was nudged in the right direction, so, from now on, we'll do
|
|
things properly.
|
|
|
|
The plan is as follows:
|
|
|
|
1. We'll have 1 _minor_ release 1-2 months (when we have some material);
|
|
1. Bug fixes will still be released as _patch_ releases in the latest _minor_;
|
|
1. Deprecations will continue to be added in _minor_ releases (but **not
|
|
removed**);
|
|
1. When we have a good amount of deprecations, we'll launch a new _major_,
|
|
removing them completely.
|
|
I think this will probably happen about once a year.
|
|
|
|
So, if you lock your CI to get `v1.x.x`, you might get new deprecation
|
|
warnings, but no breaking changes.
|
|
|
|
You can then better plan when to upgrade your apps to the latest _major_,
|
|
without having to lock to a specific _minor_/_patch_ release.
|
|
|
|
## Supporting old versions
|
|
|
|
I understand GoReleaser has become the _de-facto_ tool to release Go projects.
|
|
I don't know how many users we have (because we don't track you), but judging by
|
|
some code searches on GitHub, there are thousands of repositories using it.
|
|
|
|
GoReleaser is also a big project.
|
|
Maintaining it could already be a full-time job, but, it isn't.
|
|
I work on it on my free time, which is limited - just like yours.
|
|
|
|
All that being said, I understand that big companies and teams rely on
|
|
GoReleaser, and some don't release as often.
|
|
|
|
With that in mind, [GoReleaser Pro][gpro] customers will have more time to
|
|
update: I'll keep launching _patch_ releases of the latest _major_ containing
|
|
relevant bug fixes and security-related fixes.
|
|
|
|
If you use the OSS version, you can either pin to the previous major, or update
|
|
to the new one.
|
|
You can also get a [GoReleaser Pro][gpro] license, and help fund this project.
|
|
|
|
I haven't yet developed the exact rules for which bug fixes will get backported
|
|
or not, but I'm quite confident that it'll be a mix of "fixes for really bad
|
|
bugs" and "a customer is experiencing it and asked it to be fixed", and, of
|
|
course, any security-related fixes.
|
|
|
|
## So, when v2?
|
|
|
|
Probably in a couple of months.
|
|
|
|
Stay tuned! 📰
|
|
|
|
## Early access
|
|
|
|
Since a couple of weeks ago, we're building a new nightly automatically every
|
|
week.
|
|
|
|
You can already use _nightly_ as the version in [our GitHub Action][gha] if
|
|
you can't wait for a new feature that's already on `main`.
|
|
|
|
This works for both the Pro and OSS distributions.
|
|
|
|
## Summing up
|
|
|
|
The _TLDR_:
|
|
|
|
- new _major_ version ~yearly;
|
|
- new _minor_ version every ~two months;
|
|
- new _patch_ versions whenever its needed, in the latest _minor_ only;
|
|
- [Pro][gpro] latest version keep getting security updates and relevant bug fixes;
|
|
- _nigtlies_ weekly for both Pro and OSS;
|
|
|
|
## Thank you notes
|
|
|
|
I would like to publicly thank everyone who commented and shared both their
|
|
pains and their experiences in [the discussion that started all this][dis],
|
|
and specially, [@LandonTClipp](https://github.com/LandonTClipp), who created it.
|
|
|
|
All of us that do OpenSource know how easy a conversation like this could have
|
|
gone south. Thankfully, this was not the case here. 💌
|
|
|
|
Thank you, for real.
|
|
Thank you for patience, for the contributions, and for pointing out ways I can
|
|
make GoReleaser better.
|
|
|
|
See you all soon!
|
|
|
|
[v1]: ./2021-11-14-goreleaser-v1.md
|
|
[deprecations]: ../../deprecations.md
|
|
[dis]: https://github.com/orgs/goreleaser/discussions/4169
|
|
[gpro]: ../../pro.md
|
|
[gha]: https://github.com/goreleaser/goreleaser-action
|
|
[Sponsors]: https://github.com/caarlos0
|