Time we finally decide on a release structure for FC?
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
Time we finally decide on a release structure for FC?
We have a problem that we need to solve.
Lets figure this out, ASAP because it will drive people crazy including volunteers in the community.
Lets figure this out, ASAP because it will drive people crazy including volunteers in the community.
Alone you go faster. Together we go farther
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
Re: Time we finally decide on a release structure for FC?
Related forum links:
edit: clarrification
Alone you go faster. Together we go farther
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
Re: Time we finally decide on a release structure for FC?
It's also quite confusing that all the development builds that are being generated right now have been moved to the FreeCAD-Appimage github repo. That's obviously wrong to do because the Mac OS and Windows builds have nothing to do with the appimage.
Edit: I want to be clear that I'm not disparaging any efforts I have been going into packaging. Thanks to everybody involved with packaging freeCAD. This is just about getting everybody on the same page of what we're doing here
Edit: I want to be clear that I'm not disparaging any efforts I have been going into packaging. Thanks to everybody involved with packaging freeCAD. This is just about getting everybody on the same page of what we're doing here
Alone you go faster. Together we go farther
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
Re: Time we finally decide on a release structure for FC?
bumping for visibility and discussion
Alone you go faster. Together we go farther
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
Re: Time we finally decide on a release structure for FC?
Alone you go faster. Together we go farther
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
- adrianinsaval
- Veteran
- Posts: 5548
- Joined: Thu Apr 05, 2018 5:15 pm
Re: Time we finally decide on a release structure for FC?
Agreed, it's also less discoverable even for linux as most people are used to looking at the github release page for the FreeCAD repo.Kunda1 wrote: ↑Mon Apr 05, 2021 5:20 pm It's also quite confusing that all the development builds that are being generated right now have been moved to the FreeCAD-Appimage github repo. That's obviously wrong to do because the Mac OS and Windows builds have nothing to do with the appimage.
Edit: I want to be clear that I'm not disparaging any efforts I have been going into packaging. Thanks to everybody involved with packaging freeCAD. This is just about getting everybody on the same page of what we're doing here
The chocolatey issue is inevitable, even if the same link had been kept the checksum would have changed and the script would have failed anyway, and skipping the checksum is not a good idea. The only solution would be to have better communication with the chocolatey package maintainers or for someone else to submit PRs for this kind of change, I guess it would be accepted faster if it comes from one of the FreeCAD maintainers.
EDIT: switching the dev releases to FreeCAD-Appimage also breaks the dev packages auto update in chocolatey as they periodically check the FreeCAD release page for the dev versions, I would like to at least know if I should request that they change they algorithm so they check the Appimage repo or if eventually we will have the dev version back in the main repo?
Also, Download still points to the main repo for dev versions.
EDIT 2: they have an auto update algorithm for stable releases too it seems, and they updated so it also catches the files that end with -1 or other numbers so the issue is apparently that the package doesn't update because it doesn't find a matching 32 bit version, there's a PR to fix that though: https://github.com/chocolatey-community ... /pull/1638 should I tell them it's ok to fully drop 32bit support? (ref).
In the future what would be important is to keep this naming consistent.
Re: Time we finally decide on a release structure for FC?
A solution which could be applied in the future is to have the download links point to the freecadweb domain (e.g. freecadweb.org/downloads/latest/{win,appimage,osx,etc.}) and then have the web server route the request to the latest file automagically.
That way when someone links to FreeCAD downloads then that link will always go through the FreeCAD domain and can be pointed towards the actual latest image. Another pro to this system is that should FreeCAD change it's blob hosting away from Github, then it could transparently (for the clients) start redirecting to a new server. Also then it wouldn't be a problem to have blobs in different repos, just a bit more work server side.
Version checks could be implented by adding "X-FreeCAD-Version" (or similar) header to the HTTP responses so clients could do a HEAD request and see if their version is older and then download the file.
I see two ways to implement this:
I hope i understood the problem correctly.
That way when someone links to FreeCAD downloads then that link will always go through the FreeCAD domain and can be pointed towards the actual latest image. Another pro to this system is that should FreeCAD change it's blob hosting away from Github, then it could transparently (for the clients) start redirecting to a new server. Also then it wouldn't be a problem to have blobs in different repos, just a bit more work server side.
Version checks could be implented by adding "X-FreeCAD-Version" (or similar) header to the HTTP responses so clients could do a HEAD request and see if their version is older and then download the file.
I see two ways to implement this:
- Write querying the latest version and caching it into website code or a cronjob that populates release info to the database. The latest releases could be retrieved from https://api.github.com/repos/FreeCAD/Fr ... ses/latest and matched to each OS from the filename. Could be made completely automatic that way, so just have to publish on Github and the web site would point to the correct release, but a bit more complex to implement.
- Route it in nginx/apache/whatever the freecadweb is served by. Wouldn't be automatic and someone would have to alter the configuration files after every release, but a bit simpler to implement.
I hope i understood the problem correctly.
Re: Time we finally decide on a release structure for FC?
Thanks, the link is now fixed.adrianinsaval wrote: ↑Sat Apr 10, 2021 5:12 pm Also, Download still points to the main repo for dev versions.
Alone you go faster. Together we go farther
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
Re: Time we finally decide on a release structure for FC?
Added Back port commits to 0.19 branch as relevant link
Alone you go faster. Together we go farther
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
Re: Time we finally decide on a release structure for FC?
Maybe the freecad-appimage repo should be renamed into "FreeCAD-Bundel". We add windows and osx later on because it's a similar workflow to create these bundles.