search

bambulab / BambuStudio

PC Software for BambuLab and other 3D printers
GNU Affero General Public License v3.0
1.74k stars 242 forks source link

Document stable and development branches #3395

Open hadess opened 6 months ago

hadess commented 6 months ago

Bambu Studio Version

git

Where is the application from?

Built from source by yourself or others

OS version

Linux

Additional system information

No response

Printer

N/A

How to reproduce

It would be very useful, for the branches used for development, and stable releases were documented.

It's very uncommon for example to have branches called 1.8.2 which would contain something other than version starting in 1.8.2.x such as the recently released 1.8.4. A better name would be 1.8 or 1.8.x.

The Flatpak build requires a number of commits that were merged into the master branch, and it's very difficult to know whether commits from that branch were actually picked up in the stable branch because the commits get squashed instead of cherry-picked, meaning that automating tools can't know whether a commit already exists.

Actual results

The stable 1.8.2 branch reports:

This branch is 106 commits ahead of, 34 commits behind master.

Expected results

  1. The stable branch is named accurately for the versions it produces
  2. The stable branch cherry-picks the commits from the development master branch instead of squashing them such that a rebase can show which commits are in master and not the stable branch, and vice-versa.

Project file & Debug log uploads

N/A

Checklist of files to include

lanewei120 commented 6 months ago

we can create a new branch v1.8.4

could you help me to understand the flatpak building flow? which git commands are used when building?

hadess commented 6 months ago

we can create a new branch v1.8.4

That might be useful, but we would still need a document explaining which branch is the main development branch, and how patches are selected to go from that development branch to the stable branch, what's done to them (eg. the fact that they're getting squashed right now), and whether all the code changes that exist in the stable branch also exist in the development branch.

could you help me to understand the flatpak building flow? which git commands are used when building?

It's not very relevant to the conversation, but the manifest is here: https://github.com/flathub/com.bambulab.BambuStudio/blob/master/com.bambulab.BambuStudio.yml

The only interesting thing is that the BambuStudio source code is picked up from the master branch: https://github.com/flathub/com.bambulab.BambuStudio/blob/master/com.bambulab.BambuStudio.yml#L295 because a number of patches need to be applied to it to build (the patches are just below).

lanewei120 commented 6 months ago

I have created a branch v1.8.4 based on v1.8.2 which also includes the patches on master

is it possible to use v1.8.4 or tag v01.08.04.52?

use a tag will be more reasonable, because each release has a tag

hadess commented 6 months ago

is it possible to use v1.8.4 or use a tag?

Sure, but could you please document the branches used, and how patches are migrated from master to the stable branch?

I have created a branch v1.8.4 based on v1.8.2 which also includes the patches on master

Will patches be cherry-picked, or will you still squash changes, as was done for this change, which squashed 14 commits into one on the branch, making backporting difficult? https://github.com/bambulab/BambuStudio/commit/42453691d2bb95def26a3d9ff807062256446ec4

use a tag will be more reasonable, because each release has a tag

But if the tags are on different branches, that also means rebasing all the patches in the Flatpak, for example.

lanewei120 commented 6 months ago

is it possible to use v1.8.4 or use a tag?

Sure, but could you please document the branches used, and how patches are migrated from master to the stable branch?

I have created a branch v1.8.4 based on v1.8.2 which also includes the patches on master

Will patches be cherry-picked, or will you still squash changes, as was done for this change, which squashed 14 commits into one on the branch, making backporting difficult? 4245369

use a tag will be more reasonable, because each release has a tag

But if the tags are on different branches, that also means rebasing all the patches in the Flatpak, for example.

we have an internal git(named BBL_git) and building servers and we will sync codes between BBL_git and github

our building server will trigger a building when a patch commited previouly we pulled the codes from github master to BBL_git's master to reduce the building server's overload, we combined serveral commits into one, and after the building and internal testing passed we synced this patch to github's v1.8.2 that is what you have seen

usually we will keep the origal commits, But this time, we forgot to do this thing.

hadess commented 4 months ago

This got closed, but this wasn't documented outside this issue as far as I can see. Can you please reopen until the document is written?

lanewei120 commented 4 months ago

sure could you tell me which kind of document do you mean?

hadess commented 4 months ago

could you tell me which kind of document do you mean?

Either a paragraph in the README, or something in a HACKING.md file, which explains the different workflows above, and explains how external packagers can track the latest stable releases, for example.