software-release.md

https://bit.ly/tilt-releases

What is a release?

A software release is an important point in the history of a software repository.

Most generally it means that users can install the released software from some platform and use it as intended to get the expected results.

How do developers create a release?

Developers mark the software with git tag, e.g. git tag v0.0.1.

Git has the ability to tag specific points in a repository's history as being important. Typically, people use this functionality to mark release points (v1.0, v2.0 and so on).

-- https://git-scm.com/book/en/v2/Git-Basics-Tagging

Where do developers share a release?

Developers share their release by deploying it to a platform where users can install it from, e.g. GitHub releases for software in any languagge, PyPI for Python, or CRAN and r-universe for R.

How do users install a release?

For Python see Installing Packages.

For R, here are some examples:

• From CRAN:

install.packages("dplyr")

• From r-universe:

options(repos = c(tidyverse = 'https://tidyverse.r-universe.dev/dplyr', CRAN = 'https://cloud.r-project.org'))
install.packages('dplyr')

• From GitHub releases:

# install.packages("pak")
pak::pak("tidyverse/dplyr@*release")

When do developers create a release?

It varies across teams. For example:

• Google aims for continuous delivery.

The biggest risk to any software effort is that you end up building something that isn't useful. The earlier and more frequently you get working software in front of real users, the quicker you get feedback to find out how valuable it really is. -- Martin Fowler in Continuous Delivery

• The tidyverse team uses a continuous delivery approach for their main branch on GitHub, plus punctuated releases to GitHub-releases and CRAN whenever they feel they have something substantial to share (which they sometimes announce on their blog).

• The r2dii ecosystem followed the tidyverse approach (example blog posts).

What are we doing in the tilt ecosystem?

We're following what we successfully did with the r2dii ecosystem -- which in tun follows the tidyverse approach.

• We already use a continuous-delivery (CD) approach for the main branch of tiltToyData, tiltIndicator, tiltIndicatorAfter, and tiltWorkflows. We have continuous-integration (CI) workflows that ensure each new PR in a repo is compatible with the main branch of any other repo^1.

• We already mark versions (think release candidates) when we introduce substantial user-facing changes (e.g. see tags for tiltToyData, tiltIndicator, tiltIndicatorAfter, tiltWorkflows). For example, you can install tiltIndicator v0.0.0.9105 with pak::pak("2DegreesInvesting/tiltIndicator@v0.0.0.9105").

• We are deploying our most public code to GitHub releases and r-universe.

If our continuous-delivery approach breaks your code we have two options:

1. (Good). Let us know so we work together on adding a continuous-integration workflow for your code. When we detect our changes break your code we'll contact you to fix your code before we merge our changes.
2. (Not so good). Use renv or similar to "freeze" the tilt ecosystem in a state that works for you until you're ready to integrate your code with the latest changes in the tilt ecosystem.

What are we still not doing in the tilt ecosystem?

We're still not deploying our software to CRAN.](https://bit.ly/tilt-releases

What is a release?

A software release is an important point in the history of a software repository.

Most generally it means that users can install the released software from some platform and use it as intended to get the expected results.

How do developers create a release?

Developers mark the software with git tag, e.g. git tag v0.0.1.

Git has the ability to tag specific points in a repository's history as being important. Typically, people use this functionality to mark release points (v1.0, v2.0 and so on).

-- https://git-scm.com/book/en/v2/Git-Basics-Tagging

Where do developers share a release?

Developers share their release by deploying it to a platform where users can install it from, e.g. GitHub releases for software in any languagge, PyPI for Python, or CRAN and r-universe for R.

How do users install a release?

For Python see Installing Packages.

For R, here are some examples:

• From CRAN:

install.packages("dplyr")

• From r-universe:

options(repos = c(tidyverse = 'https://tidyverse.r-universe.dev/dplyr', CRAN = 'https://cloud.r-project.org'))
install.packages('dplyr')

• From GitHub releases:

# install.packages("pak")
pak::pak("tidyverse/dplyr@*release")

When do developers create a release?

It varies across teams. For example:

• Google aims for continuous delivery.

The biggest risk to any software effort is that you end up building something that isn't useful. The earlier and more frequently you get working software in front of real users, the quicker you get feedback to find out how valuable it really is. -- Martin Fowler in Continuous Delivery

• The tidyverse team uses a continuous delivery approach for their main branch on GitHub, plus punctuated releases to GitHub-releases and CRAN whenever they feel they have something substantial to share (which they sometimes announce on their blog).

• The r2dii ecosystem followed the tidyverse approach (example blog posts).

What are we doing in the tilt ecosystem?

We're following what we successfully did with the r2dii ecosystem -- which in tun follows the tidyverse approach.

• We use a continuous-delivery (CD) approach for the main branch of multiple packages. We have continuous-integration (CI) workflows that ensure each new PR in a repo is compatible with the main branch of any other repo.

• We mark versions (think release candidates) when we introduce substantial user-facing changes. For example, you can install tiltXYZ v0.0.0.9105 with pak::pak("2DegreesInvesting/tiltXYZ@v0.0.0.9105").

• We deploy our most public code to GitHub releases and r-universe.

If our continuous-delivery approach breaks your code we have two options:

1. Let us know so we work together on adding a continuous-integration workflow for your code. When we detect our changes break your code we'll contact you to fix your code before we merge our changes.
2. Use renv or Docker to "freeze" the tilt ecosystem in a state that works for you until you're ready to integrate your code with the latest changes in the tilt ecosystem.