search

gomods / athens

A Go module datastore and proxy
https://docs.gomods.io
MIT License
4.44k stars 502 forks source link

Introduce Release Cycles #1232

Open marwan-at-work opened 5 years ago

marwan-at-work commented 5 years ago

Currently, we release Athens when we have a lot of features and fixes that it feels like we definitely need a new release. This means that each release has so many features that it's very difficult to catch any regressions and we introduce a lot of risk of too many changes.

On the other hand, too many releases would have the same negative effect.

Therefore, we should create a sane release cycle where we ensure that we're not falling behind on new releases and we also ensure that new features are accessible in docker images quickly enough.

The release cycle should be one of the following:

  1. Weekly
  2. Bi-weekly
  3. Monthly
  4. Bi-monthly

I believe either options 2, or 3 are best. But if you feel differently please feel free to comment.

marpio commented 5 years ago

+1 I would start with 3 and switch to 2 when we have more contributions.

ghost commented 5 years ago

I agree

arschles commented 5 years ago

sounds good to me. @marwan-at-work think we should do a code freeze as part of this, or is that overkill right now?

johnjelinek commented 5 years ago

Can you do monthly? I'd really like a new release to pin against, since I depend on features in the canary release that have been there for a while.

arschles commented 5 years ago

@johnjelinek we certainly could. We've put the roadmap on the back burner for a while, and just released when we've added enough features that it "feels" (that's a highly technical term by the way 😆) like a new release.

But! I've done a bit of organizing a roadmap (which then informed when a release was gonna happen) in the past. Here is an example. Would this kind of document help you plan?