-
Notifications
You must be signed in to change notification settings - Fork 842
4. Publishing a Release
Presently, making a new release involves four different build processes for four platforms, followed by an upload step. The four platforms are:
linux 32- linux 64
- mac universal binary (for intel 64,
intel 32) windows 32- windows 64
Use Qt 5.12 LTS when possible. Linux versions should use the default Qt library of their distribution, however Qt < 5.9 is not supported anymore.
Make sure that the version string and date are updated. The files to be modified are:
FritzingInfo.plist
fritzing.rc
src/version.cpp
org.fritzing.Fritzing.appdata.xml
There is also a script that will update the date in the Copyright header of the source files at fritzing-app/tools/scripts/checkcopyright.py, but you only need to run this once or twice a year.
lupdate -noobsolete phoenix.pro
lrelease -removeidentical phoenix.pro
On the PC you can run two scripts in the tools folder (you may have to modify the script to put in the correct location for the Qt tools that are invoked): linguist_translate.bat and linguist_release.bat
Check in the resulting .ts and .qm files.
If possible, some weeks before the final build, see if you can get any translators to do an update. Run the above scripts (or equivalent) and pass the .ts files along to the appropriate translators. For obvious reasons, you should be able to talk someone into updating the German translation.
If you make changes to any of the files above, or receive any new translation files, make sure to push them to the repository so all platforms will be in sync.
One last task should be performed if any new parts have been added or .fzp files modified--the Fritzing parts database needs to be rebuilt. To rebuild the database, click Parts > Regenerate parts database... or run Fritzing from the command line:
fritzing -db path/to/parts/parts.db
Release builds are fully scripted, and currently run on travis-ci. Linux builds use a docker image, while Mac and Windows builds use the environment provided by travis. After a successful build, the binaries are copied as a draft to github releases, from where they can be published.
For completeness, the release documentation as it was before 2019: Be sure to always do a clean build for the release, since Qt isn't perfect when it comes to incremental builds. Some old files might still stick around and will only become an issue when running on another computer.
That means: Manually delete all build folders as well as the previously auto-generated Makefiles before you start the release build.
There is a good set of instructions for setting up virtual machines and building the linux releases here, so I will just add a bit of context. First, we do our builds under Ubuntu 16.04 LTS. Basically, to do the build, you use the script release.sh, and it can be found in Fritzing source in tools/linux_release_script/. Once your vm is set up correctly, you merely have to run the script with the current release string as the parameter (e.g.: ./release.sh 0.8.6b). The process will create a standalone tar.bz2 file containing the Fritzing executable plus all the necessary auxiliary files (including the qt libraries). These bz2 files are download-ready.
We are building the release for only one platform, intel-64. Releases are currently build with MacOS 10.13 (xcode 10.1) and 10.14 (xcode 10.2.1).
Because we are building for only one platform, we can just download the Qt SDK binary. If we decide to support intel-32 builds after all, it would be necessary to build Qt from source. This is not difficult, but it does take some time. There is a config step which takes about an hour, then the full build, which I usually leave to run overnight. Instructions for building Qt from source are here. Rather than putting both builds into a universal binary, I would suggest offering the 32 and 64 Fritzing builds separately.
Once Qt is ready, you can build Fritzing. Clone or pull the latest Fritzing source. First check the phoenix.pro file to make sure that the line CONFIG += x86_64 # x86 ppc has commented out the x86 and ppc directives: you only need config x86_64, and if you do a separate 32-bit build, use a 32-bit machine, config x86 and comment out the others.
You use a script to build Fritzing called deploy_fritzing_mac.sh, find it in the tools folder. You may first need to change the QTBIN folder in the script. Once you are finished checking phoenix.pro and the deploy script, run it from the terminal. The output from this script will be found in the deploy folder (which should appear above the Fritzing source tree). On the mac everything is copied into the Fritzing bundle; in other words deploy/Fritzing.app is all you need for the next build step.
The next (and last) step is to turn the fritzing bundle into a DMG. Automated builds now use macdeployqt. In the past, we used the freeware program DMG Canvas for this task, although Qt's macdeployqt now also seems to support the creation of DMGs. There is already a template canvas Fritzing.dmgCanvas in the tools folder. Double-click the canvas file, then once the application comes up add your freshly created Fritzing.app and press the Build button. In the Save As dialog that appears, change the names of the volume and the output dmg as appropriate--the current form is fritzing.{version}.osx.dmg and the volume is fritzing.{version}.osx. Version is something like 0.8.6b. The dmg file saved by DMG Canvas is what you release.
(Outdated) The Windows release is mostly built using a script. The hard part is setting up a build machine. I use Visual Studio Express 2012 for builds; it would be possible to switch to Qt Creator, but you would have to considerably revise the build process. Visual Studio Express is free and you can find the download and instructions on the net.
To start the release build, clone or pull the latest Fritzing source. Find the tools subfolder and open the file release_fritzing.bat in a text editor. If necessary, change the line that sets QTBIN so that it uses the path to your Qt SDK/bin folder. Now open up a Visual Studio 2012 command prompt; you can find this in the Start menu under: All Programs > Microsoft Visual Studio 2012 > Visual Studio Tools > Developer Command Prompt.
Drag and drop release_fritzing.bat onto the VS Command Prompt (or otherwise execute the batch file there). The batch file takes three parameters: one fort the Fritzing version, something like 0.8.6b, one for the platform, (32 or 64) and another for your version of Visual Studio, for example '2015'. The batch file takes some time to run (roughly 15 minutes on my 2.60GHz quad core pc). Once the batch file completes, you will find a file named fritzing.{version}.pc.zip in the release folder. This is the file you release.
At this point you should have five files ready to upload to fritzing.org:
a windows 32 release (.zip)- a windows 64 release (.zip)
- two mac universal binaries (.dmg) , one build with xcode 10.1 and one 10.2.1
a linux 32 release (.tar.bz2)- a linux 64 release (.tar.bz2)
There is a web-based UI to publish the releases. Go to the admin page and click on releases, then click the add new button, then fill in the form and upload the files using the platform widgets at the bottom. Make sure you really got everything right and don't need to upload a release file twice--otherwise it will automatically get renamed ".1.zip" etc, which can cause confusion for users.
The download page on fritzing.org is updated with the new set of files. I find it a very useful test to immediately download each release file from the fritzing.org download page to its appropriate platform, unarchive the download, and try to run it.
Every one of our supported platforms now has one or more app stores that users can browse to discover and install new software. We should get fritzing into each of these, which requires additional steps. None of this is set up yet, so the following just represents the state of research:
The Windows Store has been introduced with Windows 8. It is meant for apps that have a Metro style, which Fritzing currently does not support. However, "normal" Windows apps can also be listed.
Qt documentation: some hints here
The Apple App Store has been around for a while.
Linux is a special case. For each Linux flavour there are different package managers and repositories. In addition, Ubuntu has also introduced a Windows/Apple-like store.
...
COPYRIGHT FRITZING.ORG ALL RIGHTS RESERVED