wiki:WikiStart/OngoingWork/RockFlavorsOrReleases/How

Option 1: Snapshotting

In this option, the package sets are basically not modified. Autoproj's snapshotting facility is instead used to pin all packages and package sets to the state they had at release time, generating a file in autoproj/overrides.d (new folder). All release states would be saved in the relevant package set in a new release/ folder, allowing to switch between releases by copying that file into autoproj/overrides.d (would provide a trivial script for that). While not strictly necessary, we would still branch or tag the packages in order to make it easy to look at the relevant code.

Pros:

  • no modifications to the package sets
  • completely frozen in time
  • because it is completely automated, it is easy for anyone to use the same process to release their own software (internally and externally)
  • the overrides system is how people will be able to snapshot their "working code" in the future. We basically kill two birds with one stone *and* give some visibility to an important process.
  • it builds on both the snapshot and overrides systems, the former being somewhat used (at least by Virgo and HROV at MARUM) and the latter being heavily used by Rock users these days. Workarounds for limitations / problems are already known, we build on common knowledge.

Cons:

  • breaks mixing with master in all but the simple cases if the package sets are pinned as well. It basically involves copy/pasting the relevant code (autobuild, osdeps and/or source.yml) from the package set's devel branch (some discussion about that below)

Required additional implementation:

  • load overrides file in sequence in overrides.d/ (trivial)
  • in order to improve the result, we should tag the release state and make sure that autoproj snapshot uses tags instead of commit IDs. This is a plus, but not a requirement.

Option 2: Branching and streamlining

In this option, the devel package set is basically branched at the time of the release, and then modified to match what the release should be. This is the mode of operation that is being used for the first "frozen in time" release. It currently involves (I bypass the RC step for clarity):

  • Branch all master branches to the release branch/tag
  • Removing all non-release packages from the package sets
  • Modifying the source.yml files to pin the packages that are not part of Rock
  • Rename the 'stable' flavor to match the release name (supposedly so that the ROCK_FLAVOR variable becomes the "right" branch)

Pros:

  • completely frozen in time

Cons:

  • requires a lot of modifications to the package sets. It is probably time consuming and error-prone (there's quite a bit of "corrective" commits between the branch and the final, Janosch and Martin can probably tell us more about that). Moreover, the differences between the devel and stable branches are harder to evaluate given the amount of modifications.
  • mixing devel and released software is hard in all but the simplest case. It basically involves copy/pasting the relevant code (autobuild, osdeps and/or source.yml) from the package set's devel branch (some discussion about that below). Given how the two are modified, it is even more a problem than in option (1) and (3) - looking at differences is a pain.

Option 3: Updating the stable flavor

This is basically option (2) but instead of heavily modifying the package set code, it simply renames the flavor to the release name. It still requires to:

  • Branch all master branches to the release branch/tag. Because there is no major difference between the 'in-devel' package sets and the released one, the branching can be done either at release time or just before release N+1 (see Hard-freezing the release when it is created, or when the N+1 release is created below)
  • Pin the packages that are using Rock's branch scheme when using stable

Pros:

  • completely frozen in time
  • compared to (2), avoids heavy modification to the package set

Con:

  • mixing devel and released software is hard in all but the simplest case. It basically involves copy/pasting the relevant code (autobuild, osdeps and/or source.yml) from the package set's devel branch (some discussion about that below)

See https://github.com/rock-core/package_set/tree/new_release_option3 for a proof of concept (requires a 5-line patch in autoproj)

General choices

Branching vs. tagging. Tagging is the usual way some software release is pinned in most VCS (git and svn come to mind). Moreover, tags are really not meant to be updated (they can be, but it amounts to a force-push in git), while branches are. So, it ends up knowing whether the goal is to have a release branch that can be updated (branch) or not (tag).

Hard-freezing the release when it is created, or when the N+1 release is created This applies only in option (1) and (3). (2), because of its heavy modifications to the package sets, really cannot do that. Basically, in this option, the current release is the stable flavor in all but name, and people using the current release are using the master branch of the package sets. Packages are branched as usual (i.e. at release time). The branching of the package sets happens when the N+1 release is created. The obvious con is that it is possible to fuck the current release up (but being strict about merging PRs for package sets should account for that). In addition, it is very well possible to provide both a branch at release time and a branch just before release N+1, so that people can choose between full control vs. getting bug fixes in a timely manner. Doing this allows to lift the "cannot mix master and release" con of option (1) and (3), at least when using the current release.

While autoproj already has support for all that is needed, the following few things would reduce the possibility to break a release:

  • a way to easily / clearly specify source.yml data on a per-flavor basis
  • as a process, avoid changing the definition of osdeps (one should be able to modify how things are installed, for instance switching from gem to prebuilt package, but not what is installed). As a prime example, adding a new library to the boost: osdeps should be avoided, instead creating a new boost-XXX osdep.

Giving release control to the package maintainers for non-core packages. This would allow non-core packages to be updated post-release, at the discretion of the package maintainers (Link to the rationale). Given that it would require the package sets to be modified and synchronized, it is in my opinion practical only with (1) and (3). Doable in (2), but much harder. Simplest would be in a process where we hard-freeze only at N+1.

Last modified 5 years ago Last modified on 09/30/14 20:55:02