Things are sometimes broken in the nightlies, I wonder if it would make sense to offer both, e.g. as freecad and freecad-stable packages?

Ok, I've added back a freecadStable package.

Fair warning, you're likely you be asked to squash these commits. The general rule is one commit per PR.

We may also want to have a conversation about directly tracking their master.

My concern is two-fold:

1. If a user includes freecad in their systemPackages and one day it ceases to compile due to say, a change in dependencies or their buildsystem then those users stuck with a system that won't build or, if they remove it - no way to install freecad until it is updated.
2. It's going to make caching near-useless.

I suggest instead of tracking master directly, specify a hash and version it with the date.

For example, the current would have a rev of 7616153b3c31ace006169cdc2fdafab484498858, and a version of "unstable-2020-09-25".

Does that make sense?

Fair warning, you're likely you be asked to squash these commits. The general rule is one commit per PR.

I'm not sure where you got that from. Usually we have one commit per changed package (with a commit message like <package name>: 1.0 -> 2.0 or <package name>: init at 1.0 or <package name>: <other change>). Commits for multiple packages should not be squashed together. Please also don't include merge commits in PRs if possible.

We may also want to have a conversation about directly tracking their master. [...]

I think there is a slight misunderstanding here. This PR updates FreeCAD to the latest master version as of now. This version will not change until we update it the next time, in a separate PR. It will not suddenly break if new commits are pushed to the FreeCAD repository.

Fair warning, you're likely you be asked to squash these commits. The general rule is one commit per PR.

I'm not sure where you got that from. Usually we have one commit per changed package (with a commit message like <package name>: 1.0 -> 2.0 or <package name>: init at 1.0 or <package name>: <other change>). Commits for multiple packages should not be squashed together. Please also don't include merge commits in PRs if possible.

Thank you for the correction. I don't know how I misread that. Maybe I shouldn't be looking at PRs before midday? :-)

I think there is a slight misunderstanding here. This PR updates FreeCAD to the latest master version as of now. This version will not change until we update it the next time, in a separate PR. It will not suddenly break if new commits are pushed to the FreeCAD repository.

Perfect!

I think it should have been freecad and freecadUnstable as that's similar to other already established paradigms like zfs and zfsUnstable

At first I only wanted to upgrade freecad (to the git version). Personally, I would have only kept the current version.

If you think we should change the names to freecad and freecadUnstable now, we can also do that.

Given upstream does not support their stable version, I think it is fine with the current naming. I would even say we should drop freecadStable for exactly that reason. Of course, if there are users that want the stable one we could choose to still provide it.

Given upstream does not support their stable version, I think it is fine with the current naming.

ah, I was unaware of this