Discuss our release process

[scudette]

Velociraptor is developed quickly and has a lot of features, supports many target operating systems and is used in many different contexts.

In the past we had a release schedule approximately monthly. This causes problems with new features introducing new bugs at the same time as existing bugs were being fixed. Because of this, it is difficult for users to balance upgrading to new versions to fix bugs and getting access to new features.

I therefore propose a change to the way releases are managed:

1. A new release will be published as a release candidate (RC) prior to the new release landing.
2. The RC will contain new features and bug fixes since the last release.
3. Once a RC is published no new features will be added to this RC.
4. The RC will stay there for about a week or two in which time it should receive as much testing as possible.
5. Smaller Bug fixes will go into the RC unless the bug fix is deemed too complex to fix in the RC in which case it will be mentioned in the release notes.

This process should hopefully catch small bugs that slip through into the releases by giving sufficient time for testing.

[siftuser]

Possible to list out the changes, enhancements to client, server separately ? Thanks

[DAfcb]

Can you speak to versioning? Is it part of the release design to have version 0.5.9 appear with a completely different but seemingly related version in your MSI installer? All my clients show 0.59.0 installed, or 0.60.0. Is that a typo or is this some non-traditional versioning scheme? It's very confusing.

[scudette]

The versioning scheme supported by MSI is sadly lacking - it can only do major, minor and sub version without support for rc or post release numbers. So we use the scheme of combining the last two numbers into a single number.

We need the last number to issue incrementing build updates so typically a release candidate will be made with last number of 1, then as each rc is made we increment that number then finally the final release gets the next number at the last position. This is required because MSI will not upgrade a package unless it thinks the version is ahead of the installed version so the last number is always increasing so people can easily upgrade through the RC and final releases.

It would have been nice if MSI supported semantic versioning but it does not so we have to use this hack to get around it. Ultimately the version reported by velociraptor version is the correct version in all cases so what MSI has is not that important (as long as it goes up).

Usually Velociraptor is deployed via custom MSI so people can set the version to whatever they want when they create their custom msi anyway.