github.com/goreleaser/goreleaser@v1.25.1/www/docs/blog/posts/2023-09-27-release-cadence.md (about)

     1  ---
     2  date: 2023-09-27
     3  slug: release-cadence
     4  categories:
     5    - announcements
     6  authors:
     7    - caarlos0
     8  ---
     9  
    10  # Version strategy and release cadence: the future
    11  
    12  A couple of weeks ago, I got a couple of complaints about the way GoReleaser
    13  is being versioned - more precisely, the fact that deprecated options are
    14  removed in **minor** instead of **major** versions.
    15  
    16  Those complaints are valid, and today I'm announcing how I plan to move forward.
    17  
    18  <!-- more -->
    19  
    20  ## History
    21  
    22  Before we do that, I feel like I should explain how we got in this position
    23  first.
    24  
    25  GoReleaser was in a [0ver](https://0ver.org)[^joke] scheme for _almost 5 years_.
    26  We had a whopping _468 `v0.x.x` releases_.
    27  Let me repeat: **four hundred and sixty eight v zeroes**.
    28  
    29  [^joke]: yes, I know this is kind of a joke.
    30  
    31  In fact, `v1` was launched less than 2 years ago, in [November, 2022][v1].
    32  
    33  Like many other things, the way we handle deprecations was from that time.
    34  A time in which GoReleaser never had major releases, because there wasn't
    35  one: we would add the deprecation notice to the
    36  [deprecations page][deprecations] and warn about it in the release's output
    37  if you use any of them, and, after roughly 6 months, remove the deprecated
    38  option and move on with life.
    39  
    40  [Breaking changes are allowed in v0][semver-si4], so, there were no broken
    41  promises.
    42  
    43  On the other hand, `v1` is a _major_ version, so it should not introduce
    44  breaking changes.
    45  
    46  In retrospect, my mistake was never stopping to think about it again after `v1`.
    47  
    48  [semver-si4]: https://semver.org/#spec-item-4
    49  
    50  ## Going forward
    51  
    52  Thankfully, I was nudged in the right direction, so, from now on, we'll do
    53  things properly.
    54  
    55  The plan is as follows:
    56  
    57  1. We'll have 1 _minor_ release 1-2 months (when we have some material);
    58  1. Bug fixes will still be released as _patch_ releases in the latest _minor_;
    59  1. Deprecations will continue to be added in _minor_ releases (but **not
    60     removed**);
    61  1. When we have a good amount of deprecations, we'll launch a new _major_,
    62     removing them completely.
    63     I think this will probably happen about once a year.
    64  
    65  So, if you lock your CI to get `v1.x.x`, you might get new deprecation
    66  warnings, but no breaking changes.
    67  
    68  You can then better plan when to upgrade your apps to the latest _major_,
    69  without having to lock to a specific _minor_/_patch_ release.
    70  
    71  ## Supporting old versions
    72  
    73  I understand GoReleaser has become the _de-facto_ tool to release Go projects.
    74  I don't know how many users we have (because we don't track you), but judging by
    75  some code searches on GitHub, there are thousands of repositories using it.
    76  
    77  GoReleaser is also a big project.
    78  Maintaining it could already be a full-time job, but, it isn't.
    79  I work on it on my free time, which is limited - just like yours.
    80  
    81  All that being said, I understand that big companies and teams rely on
    82  GoReleaser, and some don't release as often.
    83  
    84  With that in mind, [GoReleaser Pro][gpro] customers will have more time to
    85  update: I'll keep launching _patch_ releases of the latest _major_ containing
    86  relevant bug fixes and security-related fixes.
    87  
    88  If you use the OSS version, you can either pin to the previous major, or update
    89  to the new one.
    90  You can also get a [GoReleaser Pro][gpro] license, and help fund this project.
    91  
    92  I haven't yet developed the exact rules for which bug fixes will get backported
    93  or not, but I'm quite confident that it'll be a mix of "fixes for really bad
    94  bugs" and "a customer is experiencing it and asked it to be fixed", and, of
    95  course, any security-related fixes.
    96  
    97  ## So, when v2?
    98  
    99  Probably in a couple of months.
   100  
   101  Stay tuned! 📰
   102  
   103  ## Early access
   104  
   105  Since a couple of weeks ago, we're building a new nightly automatically every
   106  week.
   107  
   108  You can already use _nightly_ as the version in [our GitHub Action][gha] if
   109  you can't wait for a new feature that's already on `main`.
   110  
   111  This works for both the Pro and OSS distributions.
   112  
   113  ## Summing up
   114  
   115  The _TLDR_:
   116  
   117  - new _major_ version ~yearly;
   118  - new _minor_ version every ~two months;
   119  - new _patch_ versions whenever its needed, in the latest _minor_ only;
   120  - [Pro][gpro] latest version keep getting security updates and relevant bug fixes;
   121  - _nigtlies_ weekly for both Pro and OSS;
   122  
   123  ## Thank you notes
   124  
   125  I would like to publicly thank everyone who commented and shared both their
   126  pains and their experiences in [the discussion that started all this][dis],
   127  and specially, [@LandonTClipp](https://github.com/LandonTClipp), who created it.
   128  
   129  All of us that do OpenSource know how easy a conversation like this could have
   130  gone south. Thankfully, this was not the case here. 💌
   131  
   132  Thank you, for real.
   133  Thank you for patience, for the contributions, and for pointing out ways I can
   134  make GoReleaser better.
   135  
   136  See you all soon!
   137  
   138  [v1]: ./2021-11-14-goreleaser-v1.md
   139  [deprecations]: ../../deprecations.md
   140  [dis]: https://github.com/orgs/goreleaser/discussions/4169
   141  [gpro]: ../../pro.md
   142  [gha]: https://github.com/goreleaser/goreleaser-action
   143  [Sponsors]: https://github.com/caarlos0