Release process #115

New issue

Closed

opened 2021-10-04 14:33:10 +00:00 by quentin · 2 comments

quentin commented

2021-10-04 14:33:10 +00:00

Owner

There are many points we may want to discuss for Garage.

Do we want to release binaries and where?
- Currently we use _release/ on Garage's bucket.
For which architectures?
- Currently, we have x86_64, aarch, armv7 and arm.
- We may add i686.
For which operating system?
- Currently, we only support Linux
- We may want to support BSD (OpenBSD, FreeBSD and maybe NetBSD), macOS and/or Windows
Which distribution method we want?
- Statically compiled binary (currently not the default)
  - Do we generate an html index that we could link to to always point to the last version (and the history)?
- Docker
  - We have a Dockerfile that copy the file from a local build
  - We may want a container built with Nix containing only a statically linked binary for maximum reproducibility
- We may publish some repositories
  - aptly, a debian/ubuntu/etc tool, can publish on a s3 target
  - doc for yum: it is also possible for Fedora/RHEL/CentOS/Mageia/etc.
Do we publish a binary on each commit for master? or only for tags?
Do we automate
- crate release?
- binary publishing?

Feel free to add your ideas and remarks

There are many points we may want to discuss for Garage. * Do we want to release binaries and where? * Currently we use `_release/` on Garage's bucket. * For which architectures? * Currently, we have x86_64, aarch, armv7 and arm. * We may add i686. * For which operating system? * Currently, we only support Linux * We may want to support BSD (OpenBSD, FreeBSD and maybe NetBSD), macOS and/or Windows * Which distribution method we want? * Statically compiled binary (currently not the default) * Do we generate an html index that we could link to to always point to the last version (and the history)? * Docker * We have a Dockerfile that copy the file from a local build * We may want a container built with Nix containing only a statically linked binary for maximum reproducibility * We may publish some repositories * [aptly](https://www.aptly.info/doc/feature/s3/), a debian/ubuntu/etc tool, can publish on a s3 target * [doc for yum](https://reece.tech/posts/hosting-centos-7-and-8-yum-repositories-in-s3/): it is also possible for Fedora/RHEL/CentOS/Mageia/etc. * Do we publish a binary on each commit for master? or only for tags? * Do we automate * crate release? * binary publishing? Feel free to add your ideas and remarks

quentin added the

kind

ideas

label 2021-10-04 14:33:10 +00:00

lx commented

2021-10-06 08:03:07 +00:00

Owner

I'm against making repositories for Debian and Fedora. We don't want to care about distribution specifics, especially if we are already giving out a statically linked binary that works everywhere.
Let's have these two methods of release: docker image for people who use docker, statically linked binary for people who don't use docker.
Having many targets (x86_64, armv7, arm, i686, etc) is good. I don't know if there are any issues specific to 32-bit platforms, do we know of any?
Supporting macOS and Windows isn't a priority.
Let's automate the build using Drone, not on each commit but under certain conditions (see below)
We can have the following schedule for building and publishing a release:
- weekly (or nightly? proably not usefull) from the master branch
- every time we release, using Drone's "promotion" feature (https://readme.drone.io/promote/)

- I'm against making repositories for Debian and Fedora. We don't want to care about distribution specifics, especially if we are already giving out a statically linked binary that works everywhere. - Let's have these two methods of release: docker image for people who use docker, statically linked binary for people who don't use docker. - Having many targets (x86_64, armv7, arm, i686, etc) is good. I don't know if there are any issues specific to 32-bit platforms, do we know of any? - Supporting macOS and Windows isn't a priority. - Let's automate the build using Drone, not on each commit but under certain conditions (see below) - We can have the following schedule for building and publishing a release: - weekly (or nightly? proably not usefull) from the master branch - every time we release, using Drone's "promotion" feature (<https://readme.drone.io/promote/>)

quentin commented

2021-10-21 15:21:27 +00:00

Author

Owner

Closing for now as we have answered many questions asked here.

quentin closed this issue

2021-10-21 15:21:27 +00:00

lx added this to the v0.5.0 milestone 2021-11-08 15:25:19 +00:00

No milestone

No project

No assignees

2 participants

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: Deuxfleurs/garage#115

No description provided.