forgejo-contrib-forgejo-cli-issues-411.md
Watch20
Star402
Fork
You've already forked forgejo-cli
CodeIssues 44Pull requests 8Releases 11Packages 2WikiActivity
Closed
opened 2026-04-13 20:00:20 +02:00 by mutablecc · 6 comments
mutablecc commented 2026-04-13 20:00:20 +02:00
Copy link
Hello,
I was trying to get an updated version of the latest dev branch, as I am running into issues with the current release and I was hoping the dev branch would fix them.
I checked out the code, and the first issue is, there's no docs in the repo to explain how to build. I googled around and eventually figured it out. I then made a Makefile with some basic targets and troubleshooting info, and began preparing a PR to submit.
But I ran into several issues:
The main branch's version is 0.4.0, whereas current release is 0.4.1. Confusing...
So I go to the repo on Codeberg and see the latest changes are to a branch called 0.4.x, where I see the version bumped to 0.4.1. Okay, so 0.4.x branch must be the latest code, right? I mean, there's another PR of another fix merged into this branch too...
But it turns out, no... main branch has newer code for src/repo.rs. In fact, 0.4.x branch seems to be an earlier branch, where a PR was merged.
So in reality what it looks like, is there is a main branch with the latest code, and an 0.4.x branch with older code, but someone has merged PRs of new fixes into the 0.4.x branch, and not updated the version in the main branch.
So, my request would be, can you please document the expected software development workflow & lifecycle for this project? If you have your own way of managing it, that's fine, I just want to know what that process is so I know how to create a PR to submit. If you can add that to a CONTRIBUTING.md file in the repo, that would be great.
I would also like to contribute a very brief README instruction for building the project, as well as a Makefile to make it a little easier to run. I can prepare that PR once I know what the expected SDLC is
Thank you
main branch's version is 0.4.0, whereas current release is 0.4.1. Confusing... - So I go to the repo on Codeberg and see the latest changes are to a branch called 0.4.x, where I see the version bumped to 0.4.1. Okay, so 0.4.x branch must be the latest code, right? I mean, there's another PR of another fix merged into this branch too... - But it turns out, no... main branch has newer code for src/repo.rs. In fact, 0.4.x branch seems to be an earlier branch, where a PR was merged. - So in reality what it looks like, is there is a main branch with the latest code, and an 0.4.x branch with older code, but someone has merged PRs of new fixes into the 0.4.x branch, and not updated the version in the main branch. So, my request would be, can you please document the expected software development workflow & lifecycle for this project? If you have your own way of managing it, that's fine, I just want to know what that process is so I know how to create a PR to submit. If you can add that to a CONTRIBUTING.md file in the repo, that would be great. I would also like to contribute a very brief README instruction for building the project, as well as a Makefile to make it a little easier to run. I can prepare that PR once I know what the expected SDLC is Thank you ### Code of Conduct - [x] I agree to act in accordance with the CoC & AI Agreement. - [x] This issue was not generated by an LLM, even in part.Cyborus commented 2026-04-13 20:26:41 +02:00
Member
Copy link
So in reality what it looks like, is there is a main branch with the latest code, and an 0.4.x branch with older code, but someone has merged PRs of new fixes into the 0.4.x branch, and not updated the version in the main branch.
That's mostly correct, except the changes in 0.4.x are also in main, the version number was just never bumped in main. The important change was !368, which was backported to 0.4.x in !371.
Development is done by creating PRs against the main branch.
can you please document the expected software development workflow & lifecycle for this project?
[...]
If you can add that to a CONTRIBUTING.md file in the repo, that would be great.
Yes, I should do that. I had started drafting a CONTRIBUTING.md semi-recently, but haven't finished it. I will continue work on it soon.
I would also like to contribute a very brief README instruction for building the project, as well as a Makefile to make it a little easier to run. I can prepare that PR once I know what the expected SDLC is
I'm not sure what the need for that is. Are cargo build and cargo run not working for you?
> So in reality what it looks like, is there is a main branch with the latest code, and an 0.4.x branch with older code, but someone has merged PRs of new fixes into the 0.4.x branch, and not updated the version in the main branch. That's mostly correct, except the changes in 0.4.x *are* also in main, the version number was just never bumped in main. The important change was !368, which was backported to 0.4.x in !371. Development is done by creating PRs against the main branch. > can you please document the expected software development workflow & lifecycle for this project? > [...] > If you can add that to a CONTRIBUTING.md file in the repo, that would be great. Yes, I should do that. I had started drafting a CONTRIBUTING.md semi-recently, but haven't finished it. I will continue work on it soon. > I would also like to contribute a very brief README instruction for building the project, as well as a Makefile to make it a little easier to run. I can prepare that PR once I know what the expected SDLC is I'm not sure what the need for that is. Are cargo build and cargo run not working for you?
LordMZTE commented 2026-04-13 21:09:40 +02:00
Collaborator
Copy link
I also don't think we need a Makefile. I don't believe that a Makefile is particularly standard or
universal, either. Even traditional C projects are often (if not most of the time) more complex to
build than make && make install (think GNU Autotools, CMake, Meson, whatnot). Documenting the
process in a CONTRIBUTING.md is definitely a good idea, though we are likely about as standard as
it gets for a Rust project. Perhaps some system libraries are also missing? Or the Rust toolchain
isn't installed? Would be great to have more details on the exact problem here.
I also don't think we need a Makefile. I don't believe that a Makefile is particularly standard or universal, either. Even traditional C projects are often (if not most of the time) more complex to build than make && make install (think GNU Autotools, CMake, Meson, whatnot). Documenting the process in a CONTRIBUTING.md is definitely a good idea, though we are likely about as standard as it gets for a Rust project. Perhaps some system libraries are also missing? Or the Rust toolchain isn't installed? Would be great to have more details on the exact problem here.
mutablecc commented 2026-04-14 00:27:43 +02:00
Author
Copy link
I'm not sure what the need for that is. Are cargo build and cargo run not working for you?
I'm not a Rust developer so I was not familiar with the typical build process. It's also nice to have some automation that encapsulates common build steps. This serves a multi-purpose function as automation for CI/CD to use (in a CI-agnostic way), a useful tool for users to discover common build commands, as well as project documentation. Pretty much all software projects that build software use some kind of file like this.
> I'm not sure what the need for that is. Are cargo build and cargo run not working for you? I'm not a Rust developer so I was not familiar with the typical build process. It's also nice to have some automation that encapsulates common build steps. This serves a multi-purpose function as automation for CI/CD to use (in a CI-agnostic way), a useful tool for users to discover common build commands, as well as project documentation. Pretty much all software projects that build software use some kind of file like this.
mutablecc commented 2026-04-14 00:32:54 +02:00
Author
Copy link
I don't believe that a Makefile is particularly standard or universal, either
You don't think the open source software build tool that's available on every operating system and architecture and has existed for 50 years is particularly standard?
The exact problem was just that I'm not a Rust developer but I can follow basic directions to be able to make a dev build of a project. Documenting those in a file in the git root is an easy way to help users. Using a tool that already exists on their system to get started is also helpful.
The problem that led me here, though, is that the repo create command wouldn't do anything no matter what arguments and options I tried, and I couldn't understand the source code to figure out what it wanted me to do, so I was just hoping the main branch had a fix.
> I don't believe that a Makefile is particularly standard or universal, either You don't think the open source software build tool that's available on every operating system and architecture and has existed for 50 years is particularly standard? The exact problem was just that I'm not a Rust developer but I can follow basic directions to be able to make a dev build of a project. Documenting those in a file in the git root is an easy way to help users. Using a tool that already exists on their system to get started is also helpful. The problem that led me here, though, is that the repo create command wouldn't do anything no matter what arguments and options I tried, and I couldn't understand the source code to figure out what it wanted me to do, so I was just hoping the main branch had a fix.
Cyborus commented 2026-04-14 02:07:15 +02:00
Member
Copy link
I'm not a Rust developer so I was not familiar with the typical build process. It's also nice to have some automation that encapsulates common build steps. This serves a multi-purpose function as automation for CI/CD to use (in a CI-agnostic way), a useful tool for users to discover common build commands, as well as project documentation. Pretty much all software projects that build software use some kind of file like this.
You checked the "this was not made by an LLM" checkbox, but this reads like the kind of sales-y fluff that does a great job of not answering my question that an LLM would output. Combining that with the fact that all of your public repos are AI-related, I'm starting to doubt you were honest there.
> I'm not a Rust developer so I was not familiar with the typical build process. It's also nice to have some automation that encapsulates common build steps. This serves a multi-purpose function as automation for CI/CD to use (in a CI-agnostic way), a useful tool for users to discover common build commands, as well as project documentation. Pretty much all software projects that build software use some kind of file like this. You checked the "this was not made by an LLM" checkbox, but this reads like the kind of sales-y fluff that does a great job of not answering my question that an LLM would output. Combining that with the fact that all of your public repos are AI-related, I'm starting to doubt you were honest there.
mutablecc commented 2026-04-14 02:17:25 +02:00
Author
Copy link
I'm a systems engineer and software engineer with 25 years experience in both open source and commercial software development. I do not need an AI to write my comments.
I really find this comment insulting, and an abuse of the power of being a maintainer, to say nothing of chasing off a potential contributor. It's an example of bad faith coming from someone with power. I find it both unprofessional and rude (and therefore possibly a violation of Codeberg's terms of service).
I won't need the documentation mentioned in this issue, and this issue is now resolved. Thank you for your time.
I'm a systems engineer and software engineer with 25 years experience in both open source and commercial software development. I do not need an AI to write my comments. I really find this comment insulting, and an abuse of the power of being a maintainer, to say nothing of chasing off a potential contributor. It's an example of bad faith coming from someone with power. I find it both unprofessional and rude (and therefore possibly a violation of Codeberg's terms of service). I won't need the documentation mentioned in this issue, and this issue is now resolved. Thank you for your time.
mutablecc closed this issue 2026-04-14 02:17:26 +02:00
Cyborus locked as Too heated and limited conversation to collaborators 2026-04-14 02:27:13 +02:00
This discussion has been locked. Commenting is limited to contributors.
No Branch/Tag specified
main
renovate/lock-file-maintenance
renovate/serde-saphyr-0.x
docs/contributing
no-port-in-refspec
login/v16.next.forgejo.org
crates-io-publish
0.5.x
compile-time-fluent
0.4.x
localization-alias-demo
api_url_field
v0.5.0
v0.4.1
v0.4.0
v0.3.0
v0.2.0
v0.1.1
v0.1.0
v0.0.4
v0.0.3
v0.0.2
v0.0.1
Labels
Clear labels[ Kind/Breaking Breaking change that won't be backward compatible
](#)[ Kind/Bug Something is not working
](#)[ Kind/Design Discussion about UI/UX design
](#)[ Kind/Documentation Documentation changes
](#)[ Kind/Enhancement Improve existing functionality
](#)[ Kind/Feature New functionality
](#)[ Kind/Security This is security issue
](#)[ Kind/Testing Issue or pull request related to testing
](#)[ Kind/Upstream This is an issue with upstream software (Forgejo) that is probably not our fault
](#)
[ Priority
Critical The priority is critical
](#)[ Priority
High The priority is high
](#)[ Priority
Low The priority is low
](#)[ Priority
Medium The priority is medium
](#)
[ Reviewed
Confirmed Issue has been confirmed
](#)[ Reviewed
Duplicate This issue or pull request already exists
](#)[ Reviewed
Invalid Invalid issue
](#)[ Reviewed
Won't Fix This issue won't be fixed
](#)
[ Status
Abandoned Somebody has started to work on this but abandoned work
](#)[ Status
Blocked Something is blocking this issue or pull request
](#)[ Status
Need More Info Feedback is required to reproduce issue or to continue work
](#)
[ Suspicious
](#)
No labels Kind/Breaking Kind/Bug Kind/Design Kind/Documentation Kind/Enhancement Kind/Feature Kind/Security Kind/Testing Kind/Upstream [ Priority
Critical ](/forgejo-contrib/forgejo-cli/issues?labels=173012) [ Priority
High ](/forgejo-contrib/forgejo-cli/issues?labels=173013) [ Priority
Low ](/forgejo-contrib/forgejo-cli/issues?labels=173015) [ Priority
Medium ](/forgejo-contrib/forgejo-cli/issues?labels=173014) [ Reviewed
Confirmed ](/forgejo-contrib/forgejo-cli/issues?labels=173007) [ Reviewed
Duplicate ](/forgejo-contrib/forgejo-cli/issues?labels=173005) [ Reviewed
Invalid ](/forgejo-contrib/forgejo-cli/issues?labels=173006) [ Reviewed
Won't Fix ](/forgejo-contrib/forgejo-cli/issues?labels=173008) [ Status
Abandoned ](/forgejo-contrib/forgejo-cli/issues?labels=173011) [ Status
Blocked ](/forgejo-contrib/forgejo-cli/issues?labels=173010) [ Status
Need More Info ](/forgejo-contrib/forgejo-cli/issues?labels=173009) Suspicious
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
Notifications Subscribe
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".
No due date set.
Dependencies
No dependencies set.
Reference
forgejo-contrib/forgejo-cli#411
WritePreview
Loading…
Add table
| Rows | | | Columns | |
CancelOK
Add a link
Url Description Hint: With a URL in your clipboard, you can paste directly into the editor to create a link.
CancelOK
CancelSave
Reference in a new issue
Repository
forgejo-contrib/forgejo-cli
Title
Body
Create issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
No Yes