Automated Releases of stable revisions

[darksidemilk]

Overview

In order to facilitate simpler releases of security fixes, small feature enhancements, and bug fixes that are reported here on github issues and in https://forums.fogproject.org, we will create github actions CI/CD flows to do a monthly (or on demand) merge of the dev-branch into a new 'stable' branch and adjust rules for other branches to follow a prod/staging/dev devops flow.

Branch plans

The general plan for the branches is as follows

Production Branches

• master - The baseline code for the latest 'build/patch' version i.e. 1.5.10 with a tagged release. This will typically have merges come in from a working
• stable - The baseline code for the latest tagged revision release, i.e. 1.5.10.41
  • This branch will be automatically cloned/merged/pulled from the current dev-branch on a monthly basis along with creating commit based release notes with a a release tag.
  • We may have a flagging system to stop the automation if a known bug exists in the dev-branch

Staging Branches

• dev-branch - Where the work for bug and security fixes takes place for regular development. The source of this branch is the master branch
• new

Development Branches

• working-{major.minor} - the working branch of beta versions for future major or minor releases. Naming of these will be flexible
• feature-branch - New features or enhancements that are being worked on and are then merged via a pull request into either a working or staging branch above and then the feature branch can be deleted. This is multiple branches for each feature, not a constant branch. These can/should be linked with github issues.

Automation

There will be a github action or actions that will run monthly (or on demand via pull request or manual run) to merge the current staging dev-branch into stable. It will either do this by an automated pull request (perhaps with some timing to allow us to stop a release) or it will simply merge the branch then tag with the current version and release based on that tag with release notes from the commit history. We'll test out a few options and see what works best.

Additional Info

Relates to #600

[mastacontrola]

This sound correct to me.

Thank you for jumping on this too!

[Neustradamus]

Dear @FOGProject team, @darksidemilk: Currently, the latest official stable release has vulnerabilities.

You can see here, to see what is the latest release:

• https://fogproject.org/
• https://fogproject.org/download
• https://forums.fogproject.org/category/22/announcements
• https://forums.fogproject.org/topic/16726/fog-1-5-10-officially-released
• https://github.com/FOGProject/fogproject/releases

Getting FOG Project
The latest release of FOG Project is 1.5.10, released March 5th 2023.

Please create FOG 1.5.11 with all vulnerability fixes specified here:

• New release? #600

Thanks in advance.

[darksidemilk]

I think you are misunderstanding.
We are not going to create a 1.5.11 for these fixes, but we are going to create a release for these fixes.
They are already fixed and the changes don't merit going from .11 in our versioning standards. 1.5.9 -> 1.5.10 had various major changes, although we've introduced many enhancements and security fixes in the dev-branch, nothing that rationalizes that level of a release.
This issue relates to how we will create a 1.5.10.41 (or later) version with all the recent fixes and future fixes will be given a more immediate release.
We will also adjust the documentation at docs.fogproject.org for default installing and the download page on fogproject.org to reflect using the new stable branch.
The stable branch now exists and you can already install from it. I might make a tag manually for the first run.
The next major release will be 1.6 which will go to the master branch, we don't currently have a set timeline for that but 1.6 is available in beta in the working-1.6 branch.

[Neustradamus]

Yes, there is a problem, a 1.5.11 is needed to fix the unsecure 1.5.10 build.

I have sent you all links previously about the current latest stable release.

The latest stable is 1.5.10.

• At right: https://github.com/FOGProject/fogproject
• Here: https://github.com/FOGProject/fogproject/releases
• https://fogproject.org/
• https://fogproject.org/download
• https://forums.fogproject.org/category/22/announcements
• https://forums.fogproject.org/topic/16726/fog-1-5-10-officially-released

Currently people always install a version with vulnerabilities.

1.6.x is another branch (developement), it is not the stable branch.

People want a new stable release with fixes.

After the 1.5.9, there was a 1.5.10.

After a unsecure 1.5.10, a 1.5.11 is needed.

More information here:

• https://semver.org/

[darksidemilk]

I understand how semantic versioning works with Major.Minor.Patch
But the FOG versions haven't followed that in terms of Patching, our 'Patch' versions like 1.5.9->1.5.10 was not a patch level change. It more followed the Minor change definitions of semver.
However semver 2.0 states "Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format." So we are kinda sorta following it with some interpretation.

In order to maintain the versioning scheme and cadence our users are familiar with, where breaking changes can sometimes occur in the 'patch' version like 1.5.9->1.5.10, we're going to utilize a x.x.x.x schema. It's kinda more like a Major.Minor.Patch.Revision but patch isn't quite right. More like SuperMajor.Major.Minor.PatchRevision

We may adjust the versioning to better follow semver's Major.Minor.Patch down the road, but we have lots of internal processes and scripting in place for the current versioning system that changing that would further delay a security release. It would also make it so the release would be more like 1.5.51 or higher with incrementing the patch version in each commit.
So we're going to go ahead and release 1.5.10.41 to address the security issues in a stable release in a timely manner.

[Neustradamus]

If you will create a 1.5.10.x release builds, you need to announce all release builds in all places and have a tag, releases in GitHub, etc.

[darksidemilk]

Yes that's the plan, it will just take some time to fully implement it, which is why we made this issue.
And thank you for mentioning the fogproject download site, I almost forgot about that.

I have manually made the first release and tag with mainly the generated release notes. Our other more major releases have more detailed release notes, but these releases will be more automated based on pulls and commits. I intend to integrate them into anywhere else we're listing release notes.

https://github.com/FOGProject/fogproject/releases/tag/1.5.10.41

[darksidemilk]

I believe this can be closed as we have the basics of this flushed out and it worked with today's release.
We now have a repo here https://github.com/FOGProject/fog-workflows that uses an internal github app for using actions across fog project repos.