Mac pre-release download way behind Windows version

[ian.rees]

Hi bronson, I think your question probably fits better under the help forum.

That said, I think the version of FreeCAD you've got isn't the latest. Try the dmg file available in the github releases (currently FreeCAD_0.16-6510.4928624-OSX-x86_64.dmg). -Ian-

[bronson]

That was it! Thanks. The SpaceMouse works great in -6510.

Arg, I thought the topmost file was the latest... should have actually read the filenames.

[ian.rees]

No worries, it's an easy mistake to make! We've been doing a lot of work around Mac releases recently and there are still a few odds-and-ends to clean up. -Ian-

[NormandC]

Guys, shouldn't these changes the OSX pre-release build is based on be merged to master before the upcoming 0.16 release?

It's only after I found this topic that I understood the discrepancy in version numbering. viewtopic.php?f=22&t=14527&p=116542#p116519

[ian.rees]

Will put a reply in the 0.16 release thread.

For posterity - there shouldn't be anything different between the generated FreeCAD executable and what's in the master - the differences in git are all about CI and making the Mac application bundle. -Ian-

[blacey]

Guys, shouldn't these changes the OSX pre-release build is based on be merged to master before the upcoming 0.16 release?

It's only after I found this topic that I understood the discrepancy in version numbering. viewtopic.php?f=22&t=14527&p=116542#p116519

That is the objective, time permitting, and as Ian mentioned, we can document the differences as well but the git commit counting approach to version numbering is a bit flawed. One challenge with merging into master right now is that the OS X builds are on the limits of what Travis-CI is willing to offer for non-enterprise accounts. While they have graciously increase build times to one hour for my account and are willing to do so for the main FreeCAD account, the builds still time out frequently and need to be restarted to complete (the aforementioned is completely automated).

The protracted build times are due to the amount of time required simply to install the port pre-requisites - for home-brew it is on the order of 20 minutes, depending upon Travis-CI infrastructure loading at the time, and for macports, indeterminate. In the background we are exploring various solutions/options, one of which is some sort of custom port-cacheing mechanism, albeit with the obvious potential drawbacks, because we would really like to stick with Travis-CI for reasons that should be obvious. Another approach may be to move to a different infrastructure, beit Circle-CI that allows 2 hour build times or an OS X server hosted somewhere with Jenkins configured to perform the builds allowing both home-brew and macports builds and on earlier OSes. I was hopeful that OCC7 might reduce the build times sufficiently to reliably come in under an hour but only time will tell... All of that said, I hope it is clear that we still have more work to do before we confidently move the OS X builds into master.

Currently the OS X builds, while on an forked repo, are fully automated. We have a process that detects git commits and will automatically perform a git merge and kick-off a Travis-CI build. If a build fails due to a timeout, it will be restarted. The OS X builds are currently labelled using the convention FreeCAD_0.16-6674.0ec81d2-OSX-x86_64.dmg that demarcates the git short-SHA for the last commit on master that is included in the build - this is to work-around the somewhat flawed git commit counting method. While @sgrogen has been doing a bang up job of consistently moving the latest OS X builds to the FreeCAD master repo in a very timely fashion, we all would like to get these OS X builds on master to give poor Chris a break

In the near term, we are working on the following:

• Port caching experimentation to reduce build times (increase predictability and make Travis-CI OS X builds tractable for the dev team members)
• Switch automated builds from using git merge to git rebase and squash OS X Travis-CI commit history to winnow down the git commit count to be +1 over master
• Port OS X build configuration into unified Travis-CI configuration in preparation for merge with master and reconfigure automated builds accordingly
• Bribe @peterl94 to gin up a home-brew formala for CalculiX leveraging @ian.rees prior macports art

Clearly we are open to other ideas and solutions but the goal remains the same - get the OS X builds onto master in a predictable, reliable way as soon as possible.

Cheers,
Bruce

[ian.rees]

One minor correction:

Bribe @peterl94 to gin up a home-brew formala for CalculiX leveraging @ian.rees prior macports art

- it's actually nglib that we need on Homebrew, there's already a CalculiX that seems to work fine.

It seems like the travis changes are more-or-less independent of the Mac application bundle work, so is there any reason we couldn't merge in the application packaging stuff to master? If we did that, I think it would be reasonable to make a one-off Mac build from the same git commit as the other platforms for 0.16 release. -Ian-

[blacey]

It seems like the travis changes are more-or-less independent of the Mac application bundle work, so is there any reason we couldn't merge in the application packaging stuff to master? If we did that, I think it would be reasonable to make a one-off Mac build from the same git commit as the other platforms for 0.16 release. -Ian-

Sure! Which of these do you consider "application packaging" from the squashed commit history? #2, #4 and #5? FYI, the .travis.yml contains the embodiment of #2 & #5 (i.e. producing an archive identifier, creating a custom disk image using the identifier and pushing the disk image to github).

Code: Select all

commit 3b5bebc866c1c6d716f7205c8bcffce5794132e8
Author: bblacey
Date:   Sat Jan 30 10:34:54 2016 -0800

    Unified Travis Linux & OSX configuation comprising:
     1. Unified .travis.yml config for linux and OS X (homebrew)
     2. New Version identifier generation convenience script for packaging
     3. Add Travis-CI build badge to GitHub README.md
     4. Modified MacAppBundle/CMakeLists.txt to configure homebrew paths to ensure proper python package path resolution (contribution from @peterl94)
     5. Use appdmg to package and deploy OS X builds (custom disk image layout)

[ian.rees]

I was looking at the differences slightly differently:

Code: Select all

Ians-MBP:freecad-code irees$ git status
HEAD detached at blacey/travis-ci-hb
nothing to commit, working directory clean
Ians-MBP:freecad-code irees$ git diff --name-only master
.travis.yml
src/MacAppBundle/CMakeLists.txt
src/MacAppBundle/DiskImage/background.png
src/MacAppBundle/DiskImage/layout.json
src/Tools/ArchiveNameFromVersionHeader.py

Given that view, my vote would be to merge in everything except .travis.yml (and maybe cleaning the trailing whitespace from the .py ), unless someone who understands Travis better than me could merge those changes in to master in a way that doesn't break CI for Linux.

My thinking (I believe like NormandC's) is that it would be nice to have the official 0.16 releases for each platform come from the same git commit. -Ian-

[blacey]

I was looking at the differences slightly differently:

Code: Select all

Ians-MBP:freecad-code irees$ git status
HEAD detached at blacey/travis-ci-hb
nothing to commit, working directory clean
Ians-MBP:freecad-code irees$ git diff --name-only master
.travis.yml
src/MacAppBundle/CMakeLists.txt
src/MacAppBundle/DiskImage/background.png
src/MacAppBundle/DiskImage/layout.json
src/Tools/ArchiveNameFromVersionHeader.py

Given that view, my vote would be to merge in everything except .travis.yml (and maybe cleaning the trailing whitespace from the .py ), unless someone who understands Travis better than me could merge those changes in to master in a way that doesn't break CI for Linux.

My thinking (I believe like NormandC's) is that it would be nice to have the official 0.16 releases for each platform come from the same git commit. -Ian-

Got it - that is easily doable. If I can take a day or two, I could also include a unified .travis.yml but comment out the os: osx so the unified .travis.yml still only build linux but all of the capability would be there... The advantage would be that any mac enthusiast or other interested party could simply uncomment the os: osx to make OS X builds but the devs wouldn't suddenly encounter OS X travis timeouts until we find a solution for that side of the equation... It would also provide a way to get feedback sooner than later.

What is the 0.16 timeframe? Said another way, do I still have a couple of days to complete the aforementioned?

Ian, longer-term, I am also thinking that if the port caching works for home-brew, perhaps a similar mechanism will work for macports so we can use Travis to continuously build against both to avoid regressions against either...