FreeCAD-Bundle
FreeCAD-Bundle copied to clipboard
FreeCAD
apply name-scheme to windows
the filename should look like this: FreeCAD_{{ release }}-{{ revision }}-{{ date }}-{{ system }}-{{ python-version }}.{{ extension }}
I noticed that now there is no mention of conda in the filename, could it be added back? my reasoning is to make it easier to direct newbies to download and test conda or libpack versions when trying to diagnose an issue, I could go to the release page and grab a direct link, but the link wouldn't last long and it's much easier for me to copy the release page link I have bookmarked.
ok i add it back. so we have: FreeCAD_{{ release }}-{{ revision }}-{{ date }}-{{ package-manager }}-{{ system }}-{{ python-version }}.{{ extension }}
I am working on it, sry.
No problem just was letting you know, just learning github not sure this was the best place to let you know
@looooo IMO it would be better to keep the naming stable since at least one downstream distribution system depends on these names, see https://github.com/chocolatey-community/chocolatey-packages/issues/1922 The current naming doesn't mention the major.minor version numbers, probably it's preferable to have those in the name but I'd like to hear @RedBaron2 's opinion on the matter, once that is settled is best not to keep changing the name scheme
for reference here's where the magic happens: https://github.com/FreeCAD/FreeCAD-Bundle/blob/master/conda/scripts/get_freecad_version.py
consider changing https://github.com/FreeCAD/FreeCAD-Bundle/blob/6b1bdb9c0d3e3cdacfe532866921fef3e5406b97/conda/scripts/get_freecad_version.py#L39 to
dev_version = "weekly-" + dev_version
if redbaron2 agrees
@adrianinsaval The current naming scheme will work, but having a heads up about changing the development releases from 20 to 21 might be helpful. Short of extraction of the exe there is no way to know currently. Thanks for keeping me in the loop.
@looooo lets make a note to remember to give @RedBaron2 a heads up if changes are made to naming schemes + new releases ?
@RedBaron2 will you consider providing v0.21 weekly dev builds via chocolatey ?
@looooo Can I ask why the FreeCAD_version.txt file lists rev_number: 29432 and the file lists 29393? @luzpaz Yes, the development files are to be released when the file name changes. I'll need to make a tweak to update for the latest Minor version.
@RedBaron2 the version file is from the source creation action. this is done multiple times a day. The bundles are only done 2 times a week (Thursday and Sunday). So this is expected.
@luzpaz @adrianinsaval
I'm working to fix the glitch that appears to hamper the FreeCAD package from updating to the chocolatey community feed. I'm running into a slight problem with getting the version from the filename of the development releases. @looooo had mentioned that this naming change was to make it uniform across the board.
How often is the minor version number updated on these releases?
-or-
Would it be acceptable to use {revision}.{year}.{month}.{date}-dev ?
@looooo from my understanding the major.minor version was removed from the filename to allow users seamless appimages updates for next versions, is so then there is no real need to remove them from the windows build, can we go back to having that in the windows filename? It would simplify stuff in chocolatey: https://github.com/chocolatey-community/chocolatey-packages/pull/1948#discussion_r928178192
@RedBaron2 the minor version changes about once a year, recent dev cycles have been longer and this time it's probably going to be longer too, {revision}.{year}.{month}.{date}-dev seems acceptable to me, what's the advantage over the current scheme? If the naming should change it should only be done for the windows releases since we want stable names for the appimages.
@adrianinsaval
The request to use the {revision}.{year}.{month}.{date}-dev for the Dev package would eliminate the need for knowing the FreeCAD Version. The current version is done to make it uniform for those not in the know.
The use of changing to the {revision}.{year}.{month}.{date}-dev versioning will also make it uniform with your appimages to a degree.
The only issue will be that the Release Notes URL will be something like https://www.freecadweb.org/wiki/Release_notes_29485.2022
A little issue.
the current format is {revision}-{year}-{month}-{date} does that not work? Is the -dev at the end important?
@adrianinsaval
Since it is a non stable release. Nuget packages must follow these releases with a tag like -dev, -alpha, or -beta
Chocolatey is based on nuget.
I suggest adding -dev in the chocolatey package only as it is redundant to point out in the filename, for now I made a PR with {revision}.{year}.{month}.{date} format for windows only, the resulting name would be something like this:
let me know if you actually need -dev in the filename and I'll at that to the PR. I don't have write permissions to this repo though so I don't know how fast it would get merged.
@adrianinsaval
I'm sorry to have confused you.
I will add the -dev to the {revision}.{year}.{month}.{date} that I get from the file name when it is updated to the github site.
The File Name currently is FreeCAD_weekly-builds-29485-2022-07-24-conda-Windows-x86_64-py38.7z I will just get the version from this so it will be 29485.2022.7.24-dev
Sorry for the confusion
Ooooh ok, I thought we had to change something here, that's perfectly acceptable, I'll close that PR then.
@adrianinsaval I'll update the PR for Chocolatey soon
and the Release NOtes url being off is NOT an Issue for you?_?
@adrianinsaval I fixed the ReleaseNotes URL problem. It just won't be added to the dev releases
@RedBaron2 the dev releases now appear to come in two versions, one built against python 3.8 (win7 compatible) and another built against python 3.10, does this cause any issue with the chocolatey packaging?
@adrianinsaval The current regex will get the first match, and with a minor tweak it found yesterday's url.