Time we finally decide on a release structure for FC?

[Kunda1]

We have a problem that we need to solve.

wmayer-v0.19-release-tag.png (610.97 KiB) Viewed 2681 times

Lets figure this out, ASAP because it will drive people crazy including volunteers in the community.

[Kunda1]

Related forum links:

• Link on Download Page Causes Chocolatey Fail
• Back port commits to 0.19 branch

edit: clarrification

[Kunda1]

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

[Kunda1]

bumping for visibility and discussion

[Kunda1]

[adrianinsaval]

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

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.

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.

[svvv]

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:

• 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.

Could also have older version routes as well with the first implementation, if it's desired, since the caching probably should be stored in a database. When someone queries freecadweb.org/downloads/latest/win/0.18 then it could get the latest windows 0.18 version download URL from the database and redirect the client there.

I hope i understood the problem correctly.

[Kunda1]

Also, Download still points to the main repo for dev versions.

Thanks, the link is now fixed.

[Kunda1]

Added Back port commits to 0.19 branch as relevant link

[looo]

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.

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.