Oolite Website Domain & Fixing the Expansions Manager

[hiran]

While we are at it...
What actually keeps us from releasing what we have? The new domain is in apparently.

Time required to prepare a release vs time actually available.

If you would like to take on the release preparation project, by all means go ahead. I cannot occupy myself with something like this right now.

So what is contained in this project? Do we have steps documented? If possible, I'd go for automation but I need to know what it is.

[another_commander]

Stable releases are manually generated. There is no official documentation, but I can show you the steps and tasks needed by using an example from the days of 1,84. The text below is the mail that had been sent to the devs mailing list of that time in order to make sure everyone was up to date with what was going to happen. This is probably the closest there is to "how to make a release" instructions. The text has been slightly edited to remove actual names of people and add the note about the changelog.

OK, here is the proposed release plan, as promised a few posts earlier:

17/07: Full freeze. Whatever revision is up on master branch at that time becomes 1.84. Please do not commit any changes to master past that date and until release is complete. I will create a new draft release on that date on github and communicate by mail the git revision which will be used for building 1.84 just to make sure that we are all on the same page.

18/07: Build binaries for all platforms, Deployment + Test Release, 32 (where applicable) & 64 bit. Windows will have updater utility for conversion to test release. That would be desired also for the other ports, but it is not necessary if it involves too much work or if we are not confident of the result. The binaries should be uploaded to the draft release on github. If that release is not visible to people other than myself (not sure because I've never done it before), then please send me download links and I will retrieve them and upload them to the draft as required. Also we need to ensure that release changelog is complete and correct.

19/07: Expected date of release. We should aim to do it as early as we can. Some coordination will be needed. We will have to do the following on that day:
- Ensure that the draft release page has all the binaries uploaded and virus-scanned.
- Have an announcement prepared already for the forum. I will make sure to have that done and reviewed well before 17/07.
- Have a new Downloads page on oolite.org ready to go, with links already pointing to the github binaries and stating that 1.84 is now the latest and recommended release, with the actual date of release.
- When ready to launch, I will make the draft release public, generating the 1.84 tag at the time of release creation. The tag should hopefully be the same as the revision used for generating our binaries, which is why we should not commit anything to master after the 17th of July.
- Getafix will have to publish the new Downloads page immediately after the github release becomes public.
- As soon as this is done, I will post the release announcement on the forum.
- Getafix will have to adjust the What's New page on the site to remove the words "Upcoming", "soon to be released" etc. where 1.84 is mentioned. The link to the release announcement on the site needs to be added to the bottom of the What's New page as well.

And then we sit back and start counting seconds until the first critical bug report.

You will have to change version numbers before any of this, of course. Instructions for version bumping are in the Doc folder of the source: https://github.com/OoliteProject/oolite ... n-bump.txt

Oh, and the Oolite Reference Sheet will probably have to be updated as well to have any references to oolite.org replaced by oolite,space and include any new keyboard settings that might have been added between 1.90 and now.

[hiran]

That is already some good stuff to look at. You said releases are to be created manually. Let's see where that is required or could be changed a little.

We already had the discussion about version numbers. Let's keep that at bay and take it still manually managed.

17/07 Full freeze: Actually we do not need a full freeze. Instead we just agree to release a specific commit id. To easily find that commit id we mark it with a tag. Subsequent commits/merges can go into the master branch, however the tag will not move. Now if we build based on the tag we get a stable version, yet further development is allowed. In case we want to allow last-minute fixes for a release, we may use a release branch instead of a tag.

18/07 Build binaries: This is already automated - we have binaries for Linux and Windows. Is the missing Apple a showstopper? Do we need to extend the automatic scripts to provide both development and release builds? Regardless of that, the build is happening on Github, and it is automatically published as prerelease. So no specific manual action here. The changelog may have to be written by us - yet I already have seen quite capable automation on that, too. Example here. Let us discuss what the important parts are.

19/07 Update website: Have a downloads page at hand, publish that page, add a new news line...
All that can be automated so if we build a release in the oolite repository it could trigger a change in the oolite-web repository. The latter is currently configured so that changes to the right branch end up being published within minutes. Let's think of coupling that. See here and here. I may need more privileges in the OoliteProject organization to set all this up.

Having an automatic message in the forum might be a challenge, but actually not a big one. We setup credentials in the forum and add them as secrets to Github. The release workflow can then send the release announcements including the changelog as a message to a new or existing thread. Yes, this automation needs to be created, it will be a couple of http requests. Let's discuss it. I may need more privileges in the OoliteProject organization to set all this up.

Ay, that reference sheet should get built together with Oolite so it always carries the correct version number. The remaining content should get updated as we see changes going into the code, which means maintaining that reference sheet should be normal workflow and not extra work for releases. How can this PDF be auto-generated? There is even a ready-to-use Github Action like this or that. Let's discuss this.

So I somehow end up with creating a tag and updating the version number manually. Not too much work - once all the automation I spoke about exists.
Our brains should not be focused with performing automatable tasks but validating what we're about to release. One of the checks could be to ensure the documentation/reference sheet contains the correct keys.
If we create such a checklist it could be ticked by many people, also non-programmers. Once we have 4eyed the checklist, we could then trigger the release.

How does that sound?

Edit: I just found https://github.com/OoliteProject/oolite ... CKLIST.TXT

[another_commander]

How does that sound?

A bit optimistic, I'd wager.

As I said, I won't be able to get involved this time. However, before putting any further effort into this, I think you should confirm these two items first:

1. Can you actually update oolite.space by committing changes to github? It looks to me that changes you make on oolite-web are applied to a CloudFlare test site that nobody knows anything about. Unless timer has switched the official Oolite website over to his own static version, oolite.space still points to the original website server somewhere in Sweden. So I don't thik you can change the website data just yet. You can easily test this by committing a temporary minor change to oolite-web (e.g. spelling of a word or a title) and check if you can see this change when you hit oolite.space in your browser. If you can see it, you are good to go. If not, then updating the site with any new release info won't be possible at this time.

2. As of yesterday, 14/06, github switched to using Node 16 instead of Node 12 for action scripts and deprecated the set-output-name command. The marvinpinto release action we have in our workflow is still at a version dating back to January 2022, uses set-output-name and, at the time of writing this, has not been updated to reflect these two changes. As a result, I expect the marvinpinto action to be broken now and I would recommend investigating an alternative action for auto-releases until it is updated.

As far as the Reference Sheet is concerned, its source file is a Libre Office Write document and is updated by hand, then the pdf gets generated. I don't know if you can automate changes to a LibreOffice document.

[Cholmondely]

Another point about the Reference Sheet.

I looked at updating it in 2020 - it is very cleverly designed to make the best use of the space available on each page. I found it impossible to rejig the first page in the space available using the relatively blunt tool of OpenOffice. (My old 1992 copy of QuarkXpress should have managed it, though).

Unlike the OoliteReadMe.pdf which just pastes in the information and takes however long it takes.

[arquebus]

Another point about the Reference Sheet.

I looked at updating it in 2020 - it is very cleverly designed to make the best use of the space available on each page. I found it impossible to rejig the first page in the space available using the relatively blunt tool of OpenOffice. (My old 1992 copy of QuarkXpress should have managed it, though).

It does need some updating, though. Some of the hotkey descriptions don't match the descriptions inside the game, and it's unclear which one is "right." The ones that come to mind right off the bat are the descriptions for the equipment selectors/triggers and the descriptions for the pylon selectors/triggers/weapons hot/cold. It feels like there may have been some feature creep that made those hotkeys do double duty and now the descriptions are a bit off.

I'm going to take some time today to compile a list of the descriptions in-game and on the ref sheet so we can work through how to improve the information presented.

[Cholmondely]

Another point about the Reference Sheet.

I looked at updating it in 2020 - it is very cleverly designed to make the best use of the space available on each page. I found it impossible to rejig the first page in the space available using the relatively blunt tool of OpenOffice. (My old 1992 copy of QuarkXpress should have managed it, though).

It does need some updating, though. Some of the hotkey descriptions don't match the descriptions inside the game, and it's unclear which one is "right." The ones that come to mind right off the bat are the descriptions for the equipment selectors/triggers and the descriptions for the pylon selectors/triggers/weapons hot/cold. It feels like there may have been some feature creep that made those hotkeys do double duty and now the descriptions are a bit off.

I'm going to take some time today to compile a list of the descriptions in-game and on the ref sheet so we can work through how to improve the information presented.

Note: Phkb has updated the Reference Sheet in the past - and might already have done so (he was talking about it after he finished his work on Keyboard Configuration). But might well not know of your issues.

Edited to add: Found it!! Here!

[arquebus]

Here is a Google Sheet that compares the in-game hotkey list with the reference sheet that currently downloads with the game:

https://docs.google.com/spreadsheets/d/ ... sp=sharing

Some of the issues are wording, where the in-game screen is going for space economy that leads to mild obscurity, but there are a few spots where the discrepancy between the two cheat sheets is significant enough to create confusion. In particular, the hotkey for injectors is just wrong for one or the other (on the sheet, I think).

The hotkeys for MFD actions read backwards in-game (cycle vs select - it *feels* to me like they should be reversed). To my mind "select" should mean "pick which MFD window you're working with" and "cycle" should mean "pick which MFD you're working with in the window that's currently selected." The version on the reference sheet is a smidge clearer (using "current" and "next" somewhat helps, but not completely). The version in-game is utterly confusing. I think "select" and "cycle" should probably just be avoided altogether and two different words should be used, or keep one word and change the other. (Maybe, for example, "cycle" and "flip", or "highlight" and "select".)

[another_commander]

What you are referring to as "in-game" is actually the result of an OXP and it is not officially supported.

You are correct about the injectors key though. It is not exactly wrong in the Reference Sheet, but it is an "I" in italics and I don't know how italics ended up there when the rest of the keys are just bold font. This should be corrected because it can indeed be confused with the slash character.

Edit: Oh, I see now what you mean by "in-game" - it is the keyboard config screen, I got confused with the keys listed by Xenon UI. Right, this is indeed bad. These discrepancies need fixing.

[hiran]

How does that sound?

A bit optimistic, I'd wager.

Ok, let's start then.

As I said, I won't be able to get involved this time.

You did a lot already by disclosing roughly what we need to look at. It does not sound impossible and it allows others to take a look and contribute.
Let us try to do something. Probably the Commanders around here just need some Admiral to overlook the actions.

However, before putting any further effort into this, I think you should confirm these two items first:

1. Can you actually update oolite.space by committing changes to github? It looks to me that changes you make on oolite-web are applied to a CloudFlare test site that nobody knows anything about. Unless timer has switched the official Oolite website over to his own static version, oolite.space still points to the original website server somewhere in Sweden. So I don't thik you can change the website data just yet. You can easily test this by committing a temporary minor change to oolite-web (e.g. spelling of a word or a title) and check if you can see this change when you hit oolite.space in your browser. If you can see it, you are good to go. If not, then updating the site with any new release info won't be possible at this time.

2. As of yesterday, 14/06, github switched to using Node 16 instead of Node 12 for action scripts and deprecated the set-output-name command. The marvinpinto release action we have in our workflow is still at a version dating back to January 2022, uses set-output-name and, at the time of writing this, has not been updated to reflect these two changes. As a result, I expect the marvinpinto action to be broken now and I would recommend investigating an alternative action for auto-releases until it is updated.

As far as the Reference Sheet is concerned, its source file is a Libre Office Write document and is updated by hand, then the pdf gets generated. I don't know if you can automate changes to a LibreOffice document.

I agree these items should be looked into, and I will have a look at the release action.

For the website I believe announcing a release is important, but first we'd need to have something to announce. So looking at the website would not be my first priority. For the long run I prefer to have a high level of automation so at any time we can decide to release and have consistent results in little time - just as today we may assume we always have the latest build available.

[timer]

ooh, I'm trying to keep track of all the posts on the forum, but yet I missed this post mentioning me

1. Can you actually update oolite.space by committing changes to github? It looks to me that changes you make on oolite-web are applied to a CloudFlare test site that nobody knows anything about.

repo oolite-web has 2 branches only-media and only-static - any commit to only-static calls auto-rebuild and updating site by CF. This site at this moment bind to domain oolite.site But this is only CF settings - what domain point at this site, and we can switch it at any time.

Unless timer has switched the official Oolite website over to his own static version

hiran can switch it too )

Main reason why not switched domain to new version is - I still developing OXP manager ( frozen due high busy by job ) and if we switch now - we lost current OXP manager manifest EDITOR, thats still working well - OXP developers can update their manifests and it will applied to main manifest file (time lag ~15min to sync with my server, I wrote about this) and then can be updated in game manager.

oolite.space still points to the original website server somewhere in Sweden. So I don't thik you can change the website data just yet. You can easily test this by committing a temporary minor change to oolite-web (e.g. spelling of a word or a title) and check if you can see this change when you hit oolite.space in your browser. If you can see it, you are good to go. If not, then updating the site with any new release info won't be possible at this time.

AC, if u want - we can test this - change domain binding in CF settings and than do any commit to only-static branch )

but for this we need do one more - change GitHub Pages domain binding settings for branch only-media to subdomain media.oolite.space
I think oolite.space will fail to load images from current media.oolite.site subdomain due browser CORS

[hiran]

2. As of yesterday, 14/06, github switched to using Node 16 instead of Node 12 for action scripts and deprecated the set-output-name command. The marvinpinto release action we have in our workflow is still at a version dating back to January 2022, uses set-output-name and, at the time of writing this, has not been updated to reflect these two changes. As a result, I expect the marvinpinto action to be broken now and I would recommend investigating an alternative action for auto-releases until it is updated.

I just tried some other build that is configured to run the marvinpinto release action. It ran successfully, even without a warning producing this output:

Code: Select all

Run marvinpinto/action-automatic-releases@latest
  
Initializing the Automatic Releases action
Determining release tags
Retrieving commit history
  Determining state of the previous release
  Searching for SHA corresponding to previous "tags/v0.1.7-installations.1" release tag
  Could not find SHA corresponding to tag "tags/v0.1.7-installations.1" (Not Found). Assuming this is the first release.
  Retrieving commits between HEAD and 3bdc571c3eac61868103bdc30888986fd0d56136
  Successfully retrieved 4 commits between HEAD and 3bdc571c3eac61868103bdc30888986fd0d56136
Generating changelog
  Adding commit "Check multiline" to the changelog
  Adding commit "Do not terminate but warn for non-existing files and directories." to the changelog
  Adding commit "Start managing installations" to the changelog
  Adding commit "Besic functionality for installation handling given." to the changelog
Generating release tag
  Attempting to create or update release tag "v0.1.7-installations.1"
  Successfully created or updated the release tag "v0.1.7-installations.1"
Deleting GitHub releases associated with the tag "v0.1.7-installations.1"
  Searching for releases corresponding to the "v0.1.7-installations.1" tag
  Could not find release associated with tag "v0.1.7-installations.1" (Not Found)
Generating new GitHub release for the "v0.1.7-installations.1" tag
  Creating new release
Uploading release artifacts
  Uploading: artifacts/OoliteStarter/OoliteStarter-0.1.7-installations.1-generic.zip
  Uploading: artifacts/OoliteStarter/OoliteStarter-0.1.7-installations.1-generic.tar.gz
  Uploading: artifacts/OoliteStarter/oolitestarter-0.1.7-installations.1_1.0-1_amd64.deb
  Uploading: artifacts/OoliteStarter/OoliteStarter 0.1.7-installations.1-1.0.exe
  Uploading: artifacts/OoliteStarter/OoliteStarter-1.0.dmg

But it is interesting that rerunning the build for Oolite we do see warnings getting generated.
So for the time being I consider that release code to be still functional, and I will keep an eye on it.

[hiran]

1. Can you actually update oolite.space by committing changes to github? It looks to me that changes you make on oolite-web are applied to a CloudFlare test site that nobody knows anything about.

repo oolite-web has 2 branches only-media and only-static - any commit to only-static calls auto-rebuild and updating site by CF. This site at this moment bind to domain oolite.site But this is only CF settings - what domain point at this site, and we can switch it at any time.

Thank you for that information, timer.

Main reason why not switched domain to new version is - I still developing OXP manager ( frozen due high busy by job ) and if we switch now - we lost current OXP manager manifest EDITOR, thats still working well - OXP developers can update their manifests and it will applied to main manifest file (time lag ~15min to sync with my server, I wrote about this) and then can be updated in game manager.

I think we should switch, even if the expansion manager manifest were a static file for the time being. But this may be another discussion that I am having with timer, and others are welcome but did so far not dive in.

oolite.space still points to the original website server somewhere in Sweden. So I don't thik you can change the website data just yet. You can easily test this by committing a temporary minor change to oolite-web (e.g. spelling of a word or a title) and check if you can see this change when you hit oolite.space in your browser. If you can see it, you are good to go. If not, then updating the site with any new release info won't be possible at this time.

AC, if u want - we can test this - change domain binding in CF settings and than do any commit to only-static branch )

but for this we need do one more - change GitHub Pages domain binding settings for branch only-media to subdomain media.oolite.space
I think oolite.space will fail to load images from current media.oolite.site subdomain due browser CORS

I just performed a change on https://github.com/OoliteProject/oolite ... nload.html, just to see that the change got visible after a minute on https://oolite.site/ (Download page).

Here is something that I dislike: The site behaves like a single page application. It is not possible to link towards a specific page, let alone to a specific section of a page. Would this be difficult to change?

[timer]

Here is something that I dislike: The site behaves like a single page application. It is not possible to link towards a specific page, let alone to a specific section of a page. Would this be difficult to change?

IMHO possible to implement by #, something like oolite.site/#downloads
ok?

[hiran]

Here is something that I dislike: The site behaves like a single page application. It is not possible to link towards a specific page, let alone to a specific section of a page. Would this be difficult to change?

IMHO possible to implement by #, something like oolite.site/#downloads
ok?

I am not sure if it is the same. I just went to oolite.space and navigated to the downloads page. The browser indicates I am on http://oolite.space/download/.

Now when I go to oolite.site and navigate to the downloads page, the browser shows https://oolite.site/. That means a user, when making a reference cannot just copy the url from the address bar as it should be oolite.site#downloads. Plus, when I manually enter https://oolite.site#downloads it changes into https://oolite.site/#downloads. Going to that URL does show the homepage instead of downloads, so it does not yet work.

But you understood what I am after, that is the first good thing. If you find something that works I will not bother if it is the original mechanism or something similar.