Prep for 3.3.0, 3.4.0, 3.5.0

[mokun]

@bevans2000

Can we do some project management here, discussing what we want to do in 3.3.x, 3.4.x, and 3.5.x respectively ?

Say if each of us will work on no more than one or two related minor issues on each of the following official release, what will they be ?

• 3.3.x
  -- e.g. Person is involved in too many Scientific studies started, research agreement (or friendliness index) between settlements #359,
  -- e.g. Not a collaborator in a scientific study, Sorting in Science Tool, Task.endTask #357

• 3.4.x
  -- e.g. Task & Building classes are not Serialised #334

• 3.5.x
  -- e.g. Cannot store previous demand Good Value, lightweight Inventory #348
  -- e.g. Excessive Specimen boxes created in disembarking (Excessive use of CopyOnWriteArrayList) #364

On the other hand, the x is just a patch version that goes after each minor version update, as you know.

So for now, if we patch a few things, we can quickly release 3.2.1, 3.2.2, 3.2.3, and so on.

Shall we ?

[bevans2000]

Yes this approach makes sense. Create some Milestones and then we can assign some Issues to them.

Also think of one big new addition/feature per release as well as improvements/refinements.

[mokun]

So, for v3.2.1, how should we update the file header ?

/**
 * Mars Simulation Project
 * SettlementConfig.java
 * @version 3.2.0 2021-07-10
 * @author Barry Evans
 */

Update all files from @Version 3.2.0 to @Version 3.2.1 ?

What about the date ?

[bevans2000]

I think we shouldn't be updating all the files just to update the release number. This creates an artificial version for every file even though they is no logical change.

[mokun]

IntelliJ complains that we have two asterisks after the slash /** and recommends one asterisk after the slash

/*
 * Mars Simulation Project
 * SettlementConfig.java
 * @date 2021-08-21
 * @author Barry Evans
 */

I don't know there is a java standard for file header.

But as we have discussed previously, you pointed out it's not that meaningful to have the @Version but the date is still good to stay, right ?

So, do you agree that the above header is what it will look like for all newly edited class files ?

[mokun]

So for the patch versions, so far we have

• 3.2.1
  -- MissionTableModel shows invisible rows #374
  -- Orbit Viewer cannot display from the view point of Mars #387
  -- Person is involved in too many Scientific studies started, research agreement (or friendliness index) between settlements #359
  -- Relocate Reporting Authority pre-configured names #412

[mokun]

We've addressed 20 issues:

• 3.3.0
  -- remove old releases of junit which are abandoned upstream and add support for junit 5  #81
  -- Task & Building classes are not Serialised #334
  -- Use unmanned drones to deliver goods between settlements #361
  -- MissionTableModel shows invisible rows #374
  -- New Idea: Regolith Processing #376
  -- Malfunction not fixed - repairers are sick or cannot find malfunction #377
  -- Orbit Viewer cannot display from the view point of Mars #387
  -- ClassCast exception starting a RescueMission #401
  -- Support multiple Crews #410
  -- Create a Scenario concept by isolating the initial Settlements #411
  -- Relocate Reporting Authority pre-configured names #412
  -- Optimize UIConfig #414
  -- Equipment constructor can identify the incorrect Settlement #415
  -- 3 methods with highest CPU usage #416
  -- Removing dangling missions #418
  -- Duplicated crew member #434
  -- NPE when loading and unloading resources from vehicle #439
  -- Cannot create new player-defined single settlement in command line #442
  -- Cannot load crew_alpha.xml in windows: File separator issue #446
  -- NPE due to threading in finding dead people #447
  See https://github.com/mars-sim/mars-sim/milestone/6?closed=1

[bevans2000]

Sounds a good idea

[mokun]

@bevans2000

Do we expect the beryx console to pop when running the Eclipse launcher "MarsProjectHeadless -new.launch" ?

Also, in a terminal, I run the console edition binary by

java -jar 3.3.0_console_java11.jar

Do we expect the beryx console to pop up to give us insight on what's happening with the simulation ?

[bevans2000]

If running in headless mode then the beryx console should not appear because that mode means there is no ui screen.
However, I see no need to keep the headless module anymore because withthe use of arguments the same can be achieved. We would add a new '-noconsole' argument to match the '-nogui' argument.
Having a new '-headless' argument would apply '-nogui -noconsole -remote' to the arguments as a shortcut.

[bevans2000]

Also if we apply #452 then the h3wdless module can go.

[mokun]

@bevans2000 @Urwumpe

So this time we'll try something new.

If we are to patch 3.3.0 by fixing any bugs in 3.3.0, we will call it 3.3.1,

Should we now create 3.3.1 branch ? Then do a pull from 3.3.1 branch and push it to 3.3.1 branch ?

[bevans2000]

We can just use the existing 3.3.0 branch as it is a bugfix of that release. I have logged a bug #460. Do you want that fixing on the branch?

[mokun]

Do you want that fixing on the branch?

Sure. Let's do it on 3.3.0 branch to see how well it fares.

[mokun]

Now that we have done a lot of work on refining the storage, we may as well focus on v3.4.0, instead of going backward to release v3.3.1. agree ?

[bevans2000]

Yes

[mokun]

What else do we still want to take care of before releasing v3.4.0 ?

[bevans2000]

Easiest approach is I will delete the 3,4.0 remote branch and just recreate it from the tag. I have removed the old branches as well because we will not create a patch release for those now. Key is to always tag the code then you can always create the branches later.

[bevans2000]

So I've deleted the 3.4.0 branch but not recreated it yet. Usually you only create a bug fix branch if you need to create a bug fix. The releases are tagged so we can always create a branch from the tag quite easily.
Also don't create the branch with the same name as the tag because it can confuse git.

[mokun]

Usually you only create a bug fix branch if you need to create a bug fix.

ok.

The releases are tagged so we can always create a branch from the tag quite easily.

Do you mean that one can recreate a branch from the tags at https://github.com/mars-sim/mars-sim/tags ?

[mokun]

Also don't create the branch with the same name as the tag because it can confuse git.

Sure. In future, I'll add a "v" before the release number on either the tag or the branch so that they are different.

[bevans2000]

Usually you only create a bug fix branch if you need to create a bug fix.

ok.

The releases are tagged so we can always create a branch from the tag quite easily.

Do you mean that one can recreate a branch from the tags at https://github.com/mars-sim/mars-sim/tags ?

Yes you can checkout the tag directly into a new branch. https://devconnected.com/how-to-checkout-git-tags/#:~:text=In%20order%20to%20checkout%20a,branch%20to%20be%20checked%20out.&text=Note%20that%20you%20will%20have,list%20from%20your%20remote%20repository.

[mokun]

So for 3.5.0, what do we want to accomplish ?

May be we should bump up more quickly and limit each minor version to have no more than three major improvement. Shall we ?

[Urwumpe]

George Clark - fit enough to ....

I'd say this log is normal. It simply says a person may have a lot of fatigue and is not suited for EVA. It prints at what task phase the person is barred from continuing the egress.

But that means he is stuck in a task that he shouldn't be doing in first place.

I would expect him to get some rest or medical care, then and be removed from regular duty for a while.

George Clark - Airlock is not in egress mode. Current task: Performing EVA Egress.

The EVA airlock is either OFF or in ingress mode. Therefore, George can't go out and will have to wait.

The problem is, that he is still trying to enter the airlock for egresss after being prohibited to do it 50 millisols (over one hour) earlier. Better would be fixing the cause, not trying again until the settler breaks. I think the check that somebody is unable to do a EVA related task happens too late then.

Defining such rules for any EVA would be easier if we could include some rules or even rulebooks applying to a task (like AOP without being AOP) and have something like exception handling available. So that general "EVA mission rules" can apply to a task (Like forbidding certain health issues, bad EVA suit state, etc.. all the time during an EVA), but how a violated rule is handled depends on the situation by defining an "exception handler" there, maybe just by switching to an emergency action.

And can I have a button or console command to extract a log of the previous actions done by a settler into a text file? That could make such analyses easier.

[bevans2000]

And can I have a button or console command to extract a log of the previous actions done by a settler into a text file? That could make such analyses easier.

Yes, depends what level of details we want. If it's just the level of the current Activity Tab then that's easy but I wonder if in this case we actually need a more detailed view. The detailed view would have to be for a shorter period than the current 5 sols.

[bevans2000]

The problem is, that he is still trying to enter the airlock for egresss after being prohibited to do it 50 millisols (over one hour) earlier. Better would be fixing the cause, not trying again until the settler breaks. I think the check that somebody is unable to do a EVA related task happens too late then.

Defining such rules for any EVA would be easier if we could include some rules or even rulebooks applying to a task (like AOP without being AOP) and have something like exception handling available. So that general "EVA mission rules" can apply to a task (Like forbidding certain health issues, bad EVA suit state, etc.. all the time during an EVA), but how a violated rule is handled depends on the situation by defining an "exception handler" there, maybe just by switching to an emergency action.

This is a common problem of the airlocks getting overloaded. I feel the cycle time is too long although I've no scientific evidence on this :-)
The Persons are healthy when they start the task but because they wait for so long, they become unhealthy. There does seem to be an underlying problem with the queuing for al airlock.

[bevans2000]

@bevans2000

DeliveryBot 002 - Early end of Unloading vehicle: LUV 012 no garage found

Can you comment on this ?

A Robot has tried to start an Unlock tsk but there is no Garage space. What is interesting is the Vehicle is a LUV which means a Construction Mission must have been done. I've never seen this scenario, how did it occur?

[mokun]

The problem is, that he is still trying to enter the airlock for egresss after being prohibited to do it 50 millisols (over one hour) earlier. Better would be fixing the cause, not trying again until the settler breaks. I think the check that somebody is unable to do a EVA related task happens too late then.

Yes agreed. I have tried to make the Walk related classes return a boolean value in such a way that it will make it impossible to even start the EVA egress. But it will need a lot of changes.

Defining such rules for any EVA would be easier if we could include some rules or even rulebooks applying to a task (like AOP without being AOP) and have something like exception handling available.

What's AOP ?

So that general "EVA mission rules" can apply to a task (Like forbidding certain health issues, bad EVA suit state, etc.. all the time during an EVA), but how a violated rule is handled depends on the situation

I've tried to create an airlock reservation queue but it wasn't successful.

May be your EVA mission ruleset could be a good approach and we can discuss more on how to implement it

[bevans2000]

I have created an issue for the Java17 upgrade #820. Do we want to do this before closing 3.5.0 or push it to 3.6.0?
I have a couple of changes left on #810 but once completed 3.5.0 is done in my mind.

[mokun]

Yes. I suppose we can switch to Java 17 now.

Perhaps one last question I have is whether the current version of kotlin is compatible with Java 17.

[bevans2000]

Yes. I suppose we can switch to Java 17 now.

Perhaps one last question I have is whether the current version of kotlin is compatible with Java 17.

Yes https://discuss.kotlinlang.org/t/using-kotlin-1-6-and-java-17-in-compose-multiplatform/23722

[bevans2000]

Good question. Do we actually need kotlin?

[mokun]

Good question. Do we actually need kotlin?

To me, it serves two purposes.

1. I want to use it to program the use of neural network.
2. FXGL uses kotlin for writing its source codes. If kotlin is installed, I will be able to look into how the API works internally.

So I hope to keep that.

Also, more and more JavaFX libraries out there are using kotlin.

[bevans2000]

JavaFX is separate now so does that mean users need an extra download to use the app ? https://blogs.oracle.com/java/post/the-future-of-javafx-and-other-java-client-roadmap-updates

[mokun]

JavaFX is separate now so does that mean users need an extra download to use the app ?

No. The FXGL maven artifact automatically takes care of selecting and downloading a version of JavaFX that it can use.

Therefore, as long as the mars-sim-fxgl submodule is being used, users won't need to download JavaFX separately and won't need to install it manually :D

[bevans2000]

@mokun When are we going to close down 3.5.0? Java 17 is done. I'm not making any more changes under 3.5.0 now. I think we just need to check the current master code base with some runs.

[mokun]

Sure. Should we change them to post-3.5.0 or pre-3.6.0 instead ?

[bevans2000]

It's done and I have started creating a page to the Wiki detailing the steps for a release. Do you want to update it with anything I have missed.
https://github.com/mars-sim/mars-sim/wiki/Release-Procedure

[mokun]

Wiki detailing the steps for a release.

That's thoughtful !

It's certainly good to have this wiki. Not only is it great for the continuity of this open source project, but also for being thorough in formalizing and documenting exactly what we do when publishing an official release.

[mokun]

I've just edited this wiki.

btw, we should update the Roadmap. It was woefully outdated.

[bevans2000]

Yes I thought it makes to document the steps. Ideally we should automate the changes with a GitFlow action but that might be wishful thinking.