Simplify release process

[hiran]

As pointed out here, the release process of Oolite takes some effort: https://bb.oolite.space/viewtopic.php?p=289632#p289632
However the focus of the original thread was for newcomers to get Oolite configured correctly, and I'd like to not dilute that.

Therefore In this thread let's discuss and track the progress on simplifying the release process such that

- all tedious technical tasks are handled by automation
- basically only the approval steps need to be done manually

[hiran]

The necessary version bump means that the version number needs to go into a multitude of files.

As one preparation step I removed the need to store odt and pdf documentation in parallel in the repository. Instead the pdf documentation will be automatically generated. Once merged, we can think of automatically distributing the version numbers into the various documents.
Please have a look at pull request 429. Feedback is welcome.

[Cholmondely]

The necessary version bump means that the version number needs to go into a multitude of files.

As one preparation step I removed the need to store odt and pdf documentation in parallel in the repository. Instead the pdf documentation will be automatically generated. Once merged, we can think of automatically distributing the version numbers into the various documents.
Please have a look at pull request 429. Feedback is welcome.

Might it be an idea to add the AppleMac documentation just in case somebody ever appears to maintain the original? Or is it a pain in the unmentionables?

[hiran]

The necessary version bump means that the version number needs to go into a multitude of files.

As one preparation step I removed the need to store odt and pdf documentation in parallel in the repository. Instead the pdf documentation will be automatically generated. Once merged, we can think of automatically distributing the version numbers into the various documents.
Please have a look at pull request 429. Feedback is welcome.

Might it be an idea to add the AppleMac documentation just in case somebody ever appears to maintain the original? Or is it a pain in the unmentionables?

The PDF documentation is generic and applicable to all builds. The problem is that the AppleMac build fails continuously and we have noone to fix it.
Hence the AppleMac is not contained at all in the current build action. I am willing to add it again if someone can provides a working algorithm.

[another_commander]

I won't be able to check the PR for a good while, but just looking at the artifacts produced I can tell you right away that Advice For New Commanders is completely messed up - fonts, page layout, page margins, etc. Viewing on MS Edge, which displays the previous version of the pdf perfectly fine.

[hiran]

I won't be able to check the PR for a good while, but just looking at the artifacts produced I can tell you right away that Advice For New Commanders is completely messed up - fonts, page layout, page margins, etc. Viewing on MS Edge, which displays the previous version of the pdf perfectly fine.

I checked. Text-wise it is the same and acceptable. But you are right on the fonts.
I guess for some reason the fonts we have available on Github are not those that were used to create the documents.

Apart from the look and feel - is there something specific about the fonts? Some historic meaning? How broad is the margin for me to take something similar?

[another_commander]

The page layout is nothing like the original as well. There is a whole new page generated compared to the original and at least one of the pics is sitting right at the bottom of one of the pages. It's just plain wrong and I would not say it is anything like acceptable. The generated pdfs should be at least exact copies of the odt sources.

I am not really sure what is gained by automating the pdf creation. Devs still need to remember to update the source .odt files before release and generating the pdfs themselves takes no more than 30 seconds, If, on top of that, the auto-pdfs are worse quality than what we had before, then I don't know what the point is.

[hiran]

The page layout is nothing like the original as well. There is a whole new page generated compared to the original and at least one of the pics is sitting right at the bottom of one of the pages. It's just plain wrong and I would not say it is anything like acceptable. The generated pdfs should be at least exact copies of the odt sources.

If you look at the heading it uses a different font. The letters are wider, therefore the heading spans across two lines. Almost all the rest of the layout is pushed to make up for that space so i consider it a consequence, not the root cause.

In the meantime I found out that whoever created the document made use of the Impact font, which is part of the msttcorefonts package. To get that installed one must accept Microsoft's "TrueType core fonts for the WebEULA". Since implicitly in the past we had this font anyway I will try to add it to the build process.

I am not really sure what is gained by automating the pdf creation. Devs still need to remember to update the source .odt files before release and generating the pdfs themselves takes no more than 30 seconds, If, on top of that, the auto-pdfs are worse quality than what we had before, then I don't know what the point is.

Then keep doing such stuff manually and do not complain about not having the time. For me this is just one step of those that I mentioned for automation.

[hiran]

In the meantime I found out that whoever created the document made use of the Impact font, which is part of the msttcorefonts package. To get that installed one must accept Microsoft's "TrueType core fonts for the WebEULA". Since implicitly in the past we had this font anyway I will try to add it to the build process.

Ok, Impact is added. The new document looks a lot better. It comes back to four pages. Yet the layout is still not exactly what we used to have.

I identified another fond, Consolas. This one seems from Microsoft as well, contained in the Vista package or the PowerPoint viewer.
https://superuser.com/questions/7904/in ... -on-ubuntu

Here I suggest we switch to the Liberation Mono font at 7pt. It would restore the formatting on the Notes section. The changed odt is pushed and converted. How does it look now?

[another_commander]

Indeed, much better now. Yeah, no problem if you want to try a different font, if it helps. As long as the pdf is a faithful reproduction of the odt, it should be OK.

[hiran]

Indeed, much better now. Yeah, no problem if you want to try a different font, if it helps. As long as the pdf is a faithful reproduction of the odt, it should be OK.

Thank you. In that case let's merge the PR.

[another_commander]

Is the oolite-doc artifact needed? The pdfs are already included in the Windows installer and I believe also in the Linux one. Not sure if the new workflow will release them as separate files, but if this is the case then it is probably not needed.

[hiran]

Is the oolite-doc artifact needed? The pdfs are already included in the Windows installer and I believe also in the Linux one. Not sure if the new workflow will release them as separate files, but if this is the case then it is probably not needed.

It is needed to transport an intermediate result from the first build step into the two other ones.
However that should not show up in the release. It is building right now, so in a few minutes we know.

[hiran]

However that should not show up in the release. It is building right now, so in a few minutes we know.

Seems to have worked as planned.
https://github.com/OoliteProject/oolite ... tag/latest

[Cholmondely]

Just wondering: might it be possible to include Disembodied's Mr Gimlet in the game somehow?

As part of the Start New Commander sequence? Or as part of the Tutorial?