Prepare a new release and document the process #4496
Comments
|
Few reasons we haven't done this, I've been waiting on #4427 to be finished but @pcercuei seems to have been away a lot. It's a real shame as I think it'll be a great addition to the build process. The CMake stuff has taken a while to work but I think that's now ready. I haven't been following along too closely since I want it to work on Linux (and OSX?) before I even try to use it with Visual Studio. I've got a branch of #4427 and have just tried to update it to master, so I'll give that a go and see if it creates a usable windows package after merging latest into it. |
|
I'm still here, just travelling around without a computer. I will be back next week. |
|
I have a fork of the branch with latest code, some hacking around in it but it does produce an installer now. Hopefully I'll test tomorrow. Hope you're having fun @pcercuei, I look forward to you getting back us getting this integrated :) |
|
Do remind me:
|
|
Sort of:
|
|
Damn. My installer doesn't work. It puts the |
|
@fluffyfreak: this is with #4427 rebased on top of master? |
|
Genuine noob question: If I'm able to build from source on a given platform and pack it into a .7z file (and document the whole process), is that acceptable? I ask because I can build for Windows and Linux (without CMake though), and I'd be happy to provide both of them if that's what we're looking for. |
|
@abbottjord94 Thanks for the offer, but no. We can also build on linux and windows, after all, that's how we do our development. The idea is to get it automated. |
|
Making the Windows release should be a matter of publishing the setup.exe built by AppVeyor once PR #4427 is updated and merged. For Linux, the JSON and appdata files at https:/flathub/net.pioneerspacesim.Pioneer should be updated, then the software appstores of (recent) Linux distributions will provide the update. Additionally a .flatpakref (~10-lines text) file can be provided for download on Pioneer's main page, which will open with the distribution's software appstore. The actual build would be hosted for free on Flathub. For OSX... I don't know. I have experience with creating OSX bundles in CMake, maybe we could setup Travis to build Pioneer just like we will do on Windows with Appveyor. Then the release process would be the same as for Windows, just download and publish a build artifact. |
|
I'm sorry, but could you clarify "the software appstores of recent Linux
distributions will provide the update" ? Because AFAIK Flatpak support
doesn't come out of the box in all Linux distribution, although I'm
guessing it does on those shipping Gnome as their default Desktop.
…On Sat, Dec 1, 2018 at 9:53 AM Paul Cercueil ***@***.***> wrote:
Making the Windows release should be a matter of publishing the setup.exe
built by AppVeyor once PR #4427
<#4427> is updated and
merged.
For Linux, the JSON and appdata files at
https:/flathub/net.pioneerspacesim.Pioneer should be updated,
then the software appstores of (recent) Linux distributions will provide
the update. Additionally a .flatpakref (~10-lines text) file can be
provided for download on Pioneer's main page, which will open with the
distribution's software appstore. The actual build would be hosted for free
on Flathub.
For OSX... I don't know. I have experience with creating OSX bundles in
CMake, maybe we could setup Travis to build Pioneer just like we will do on
Windows with Appveyor. Then the release process would be the same as for
Windows, just download and publish a build artifact.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#4496 (comment)>,
or mute the thread
<https:/notifications/unsubscribe-auth/AAkONTVoUaNY9aF0AcF927-TbRV_7D2pks5u0kOmgaJpZM4Yyiqm>
.
|
|
It's not out of the box on all distributions (yet), but the page on Flathub to download Pioneer (https://flathub.org/apps/details/net.pioneerspacesim.Pioneer) already links to a setup guide for your distribution. |
|
IMO this is actually a regression for our users compared to the
previous ad-hoc setup (which was simply a tarball) : you now need at
some point administrative access to your computer.
…On Sun, Dec 2, 2018 at 11:24 AM Paul Cercueil ***@***.***> wrote:
It's not out of the box on all distributions (yet), but the page on Flathub to download Pioneer (https://flathub.org/apps/details/net.pioneerspacesim.Pioneer) already links to a setup guide for your distribution.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Actually you can install flatpaks as user, from the command line at least (from the GUIs I think they are installed system-wide). Note that we can very well release as a tarball as well, and on the website, just notify that a flatpak version is also available. |
But won't flatpack make a package that's compatible with the linux distro the user is on? Our current problem is our tar-ball only works for (most common) ubuntu / debian distros, which I thought flatpack would solve? |
|
I'm not saying that there is no upside to flatpaks, I'm just wary of
regressions, and want to make sure that's taken into account. I'm not
particularly wild about pointing our users to something that's generated
and hosted by a third-party, too, if I understood correctly what's going
on, but then again that's also what we would be doing with the Windows
setup anyway, except for the hosting part.
…On Sun, Dec 2, 2018 at 2:26 PM Karl F ***@***.***> wrote:
IMO this is actually a regression for our users
But won't flatpack make a package that's compatible with the linux distro
the user is on? Our current problem is our tar-ball only works for (most
common) ubuntu / debian distros, which I thought flatpack would solve?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#4496 (comment)>,
or mute the thread
<https:/notifications/unsubscribe-auth/AAkONaKu3nnXNn2UxnZju7XzT8kQ7hfRks5u09UUgaJpZM4Yyiqm>
.
|
|
Tarball (well, zipfile) Linux builds via Travis are already complete in master, the Travisfile just needs a repo key to upload the release binaries to the GH release. The rest of the builds are outside of my realm of expertise, so I can't comment on them. |
|
Should it be automatically uploaded to github then? We can also do that from appveyor. |
|
I'm in favor of uploading all binaries to the appropriate Github release, and mirroring full releases (e.g. no RCs or pre-alpha builds) on the website/sourceforge proper. Travis can handle that for both our Linux and macOS builds (assuming we get the previous OSX maintainer to port their build process to the Travisfile), and Appveyor can handle the Windows side of things. To move forward at this point, @pcercuei needs to finalize the Appveyor setup, @impaktor or @ecraven needs to generate a API token with write access to the repo's releases (see Travis/Github docs for the process), and I need to write this all down in Once we have builds from Appveyor and Travis successfully uploading to github releases (aka tags), the PR manager is responsible for uploading the build artifacts to Sourceforge, writing up the new release announcement, and broadcasting the news on Twitter/Mastodon/wherever. |
I'd vote to have the documentation on wiki or something. Not sure the documentation of how we, the devs, publish the builds need to be in the source tree.
Usually, Changelog.txt is the only thing we use + I publish the highlights on twitter.
Yeah, I gave them a look but it wasn't obvious to me what needed to be done. I don't know much about euthentication keys, and whatnot, and I didn't follow the jargon of the docs, i.e. I need doc to understand the doc. I'm sure others understand it better. |
|
I'm rather partial to having this documented in the source tree. This
documentation is conceptually similar to COMPILING.txt, IMHO. Otherwise,
this all sounds good to me.
…On Wed, Dec 12, 2018 at 9:15 AM Karl F ***@***.***> wrote:
and I need to write this all down in PUBLISHING.txt or similar.
I'd vote to have the documentation on wiki or something. Not sure the
documentation of how we, the devs, publish the builds need to be in the
source tree.
writing up the new release announcement
Usually, Changelog.txt is the only thing we use + I publish the highlights
on twitter.
needs to generate a API token with write access to the repo's releases
Yeah, I gave them a look but it wasn't obvious to me what needed to be
done. I don't know much about euthentication keys, and whatnot, and I
didn't follow the jargon of the docs, i.e. I need doc to understand the
doc. I'm sure others understand it better.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#4496 (comment)>,
or mute the thread
<https:/notifications/unsubscribe-auth/AAkONQ0-7R5_DGpB4wDK2fKkHCVSS7-Hks5u4LsOgaJpZM4Yyiqm>
.
|
OK, fine. your wish is my command... |
|
Do I need to support 32-bit Windows? (that would require more work) |
|
I think we prioritize any solution that 1. works, 2. is completed soonish, rather than a utopian solution that stalls a release for more indefinite time. So, I'd say it's up to the person doing the job to decide how far they take it. So if we just get 64 bit support, that's OK with me. |
|
+1.
We're volunteers. If someone wants a 32-bit build, they can always do
it themselves, or at least open an issue :)
…On Wed, Dec 12, 2018 at 12:28 PM Karl F ***@***.***> wrote:
I think we prioritize any solution that 1. works, 2. is completed soonish, rather than a utopian solution that stalls a release for more indefinite time. So, I'd say it's up to the person doing the job to decide how far they take it. So if we just get 64 bit support, that's OK with me.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
@impaktor To generate an access token, you need to do two things. First, you need to go to https:/settings/tokens/new and generate a token with the Next, you need to install the travis CLI via Line 50 in ae12a64 Now travis jobs running on the main repo have authorization to deploy release binaries to our Github releases. |
|
@Web-eWorks ☝️ done? So if we push a tag, it will now do a GNU/Linux build and upload to github, I assume? |
|
I have to fix the build script first, but yes. |
|
Figured it out! Not shutting things down on exit is what causes the access violation. So there's a fix incoming. For some reason it works fine if the modelcompiler is built using VS201X, or on Linux, or on OSX. But if it's built by mingw-g++ for Windows ... then it has the problem. The next problem is that it doesn't actually build any |
|
Fixes for the access violation in #4518 but the modelcompiler searching the wrong location will need someone who understands the CMake stuff to figure out. I tried changing the working directory to the one with |
|
The modelcompiler is already called by CMake in the top-level folder, not in the build folder, so it should be able to find the data. |
|
We now have an appveyor pioneer project page (thanks @pcercuei ); and I just added appveyor build badge to the readme. I wonder if I need to invite pinoeer "owners" to pioneer's appveyor account, or do you guys have access throuhgh loggin in to it with your github account? If not so, bump me, and I'll send appveyor team invite. |
|
So Appveyor does successfully build pioneer now, the only problem is the naming of the file. The script that uploads the output to github release page needs to know the name of the file that was buildt, and ideally we would like the name to be yyyy-mm-dd. So not sure what the sane way to do this is. Appveyor does allow setting versioning, but I don't quite understand it. Maybe this post (from 2015) might be of interest, it uses powershell: |
|
HOLY MOLY, in two days it's been 1 year since last release! ALL HANDS ON DECK! RED ALERT! - ASCHTUNG! I suggest we just manually make windows and linux upload, asap, and upload manually. I think sourceforge is the only pioneer-system I don't have loggin to, so... this likely falls on @fluffyfreak, really sorry to swamp you with stuff to do. So basically rename this latest appveryor build, and upload, please (and can someone test it as well, just that game starts and ship takes off without total crash?): (from https://ci.appveyor.com/project/pioneerspacesim/pioneer/builds/21861028/artifacts ) |
|
|
|
That windows installer throws an error after starting it: |
|
The Windows installer didn't give me an error. |
|
On a second run, the error did not pop up here either. |
|
I've removed the version string from the ISS naming so that appveyor does a successful build again. Just waiting for that to finish, then I'll test and upload to Sourceforge. |
|
Release is here https:/pioneerspacesim/pioneer/releases/tag/20190203 |
|
The AppStream data (metadata/net.pioneerspacesim.Pioneer.appdata.xml) was not modified to add the release information, could you add it? |
|
Is there something somewhere, like on the wiki, that tells me what needs to be added because I've never heard of this EDIT: I figured the releases bit is just the bit at the end with the tag and date so updated that, hope it was correct |
|
Just add a new line below this one: https:/pioneerspacesim/pioneer/blob/master/metadata/net.pioneerspacesim.Pioneer.appdata.xml#L59 Put a new tag just like the already existing one (don't remove it), with this release's date. |
|
@fluffyfreak, the |
Also, thanks @fluffyfreak for fixing this! (meet each other back here in a year?) |
|
@impaktor, yes, a good practice would be to edit that file to add the new release just right before tagging the release. Oh, and AppStream complains that the two I updated the flatpak recipe. Now you can install Pioneer from here for 32-bit and 64-bit x86, as well as 32-bit and 64-bit ARM. Clicking the "Install" button actually downloads a simple text file, that app stores will parse. This text file can be hosted on the pioneerspacesim.net too. |
|
Cool, I've linked to the flatpak from the release notes on github, we should link to it from our homepage as well, and maybe the wiki. I've fixed the |
|
@fluffyfreak can I ask you to rename the sourceforge files you uploaded to the same format as previous, so maybe pioneer website script picks them up, assuming @robn's script/cron job is still working. EDIT I realize the windows build now is *exe, so renaming that might be a problem... unless we zip the exe... "we".... |
|
I think that's gonna require the website to change to be honest. I don't even know how to rename them, it seems needlessly complicated to do anything with Sourceforge... |
|
@fluffyfreak done. @ecraven just launched our new webpage, we have a new repo for it, please comment or PR, or whatever. @pcercuei how would one best link the flatpak thingy? Does that build against current master, or against latest tag/release? |
|
The direct download link for the flatpak thingy: https://flathub.org/repo/appstream/net.pioneerspacesim.Pioneer.flatpakref. It will always point to the latest version. The package itself must be updated manually at each release, but it's as simple as updating the source download link and MD5 sum in the recipe. |
|
Wow you guys have some problems :D . I would suggest for a linux build to rent a 5$ box and write a script to
Looks maybe to simple, idfk. Same can be done with a windows box, no idea here. |
|
four years later, and just having made a new release the other day, I've documented everything I know, and who's responsible for each thin to do here: |
It's been a while since we've had a new release, and that's a shame. However, our build system has evolved quite a bit, and I've basically been told that we don't know how to do releases anymore.
The process might simply be "tag a commit, wait for defined $people to build on their respective platforms, upload the builds, then do the whole website/twitter/stuff dance", but it still has to be documented.
Oh and I'm not volunteering.
The text was updated successfully, but these errors were encountered: