search

FOGProject / fogproject

An open source computer cloning & management system
https://fogproject.org
GNU General Public License v3.0
1.1k stars 221 forks source link

Automated Releases of stable revisions #601

Closed darksidemilk closed 4 weeks ago

darksidemilk commented 1 month ago

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

Staging Branches

Development Branches

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 commented 1 month ago

This sound correct to me.

Thank you for jumping on this too!

Neustradamus commented 1 month ago

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

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

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:

Thanks in advance.

darksidemilk commented 1 month ago

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 commented 1 month ago

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.

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:

darksidemilk commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 4 weeks ago

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.