Release process #115

Closed
opened 2021-10-04 14:33:10 +00:00 by quentin · 2 comments
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
Ideas
label 2021-10-04 14:33:10 +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:

- 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/>)
Author
Owner

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

Closing for now as we have answered many questions asked here.
lx added this to the v0.5.0 milestone 2021-11-08 15:25:19 +00:00
Sign in to join this conversation.
No Milestone
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.