beta builds?

[wsu-cb]

Would it be possible to make beta/pre-release builds available now? I would like to be able to publish my GMT Space Empires .gbx, but it depends on some new features.

I'm afraid I'm not motivated to work on the WinState #42 problem since I still have hopes of eventually porting to wxWidgets which will almost certainly require another WinState rewrite.

That leaves the HiDPI #19 problem. Do you see that as a showstopper?

[DLLarson]

Hi Bill,

Would it be possible to make beta/pre-release builds available now? I would like to be able to publish my GMT Space Empires .gbx, but it depends on some new features.

If you'd like to publish betas please give it a go. I believe you have the access level to do so. If not we can change that real quick. I'm heads down studying the graphics code (and doing occasional PR inspections of course.)

That leaves the HiDPI #19 problem. Do you see that as a showstopper?

Right now the code works fine as is but you get the tiny stuff on High DPI screens.

I'm initially focusing on how I can do the integer multiple approach we discussed. But I can't give an estimate on when It'll be ready yet.

If that works we would probably want a way to turn it off just-in-case which may mean the file format would need to carry an additional flag or perhaps it could be stores as a registry setting. It seems like it should be an application level setting so maybe the registry would be the right place to put it. In that case it wouldn't impact any beta's you publish.

-Dale

[wsu-cb]

If you'd like to publish betas please give it a go. I believe you have the access level to do so. If not we can change that real quick. I'm heads down studying the graphics code (and doing occasional PR inspections of course.)

Have we firmly decided that this is CB 4.0, not CB 3.5?

Also, is there github documentation for making a release? I have no idea how one does that.

If that works we would probably want a way to turn it off just-in-case which may mean the file format would need to carry an additional flag or perhaps it could be stores as a registry setting. It seems like it should be an application level setting so maybe the registry would be the right place to put it. In that case it wouldn't impact any beta's you publish.

That does seem like a system, not .gam/.gbx, setting.

[DLLarson]

Have we firmly decided that this is CB 4.0, not CB 3.5?

I'm good with that. I think that adding the multi-face pieces and expanding the number of possible pieces are pretty big deal changes.

Also, is there github documentation for making a release? I have no idea how one does that.

I was just building them manually and posting them. But I'm pretty sure Github has the capability of creating releases since it already knows how to build the code. Here's what I could find for documentation:

https://docs.github.com/en/repositories/releasing-projects-on-github/about-releases
https://github.com/marketplace/actions/automatic-releases

That does seem like a system, not .gam/.gbx, setting.

Agreed. We'll go with that.

-Dale

[wsu-cb]

Also, is there github documentation for making a release? I have no idea how one does that.

I was just building them manually and posting them. But I'm pretty sure Github has the capability of creating releases since it already knows how to build the code. Here's what I could find for documentation:

https://docs.github.com/en/repositories/releasing-projects-on-github/about-releases https://github.com/marketplace/actions/automatic-releases

It would be great to use the builds that Github is already generating, but those links don't provide clear info on how to do that.
I see some documentation about preserving build output at https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts#uploading-build-and-test-artifacts, but it talks about things like billing, so I hesitate to try any of those actions myself. Also, I have never written Github workflows, so that would probably require significant research time. I think I will have to manually build and upload from my personal machine.

[DLLarson]

Also, I have never written Github workflows, so that would probably require significant research time. I think I will have to manually build and upload from my personal machine.

What I did to figure out how to do the build was to look for similar projects and saw what they did.

I think it's fine to build them yourself until we figure it out. That's what I was doing. I've found that GitHub actions are mega-powerful but they can be as clear as mud when it comes to figuring them out. It's a declarative language.

GH Actions seem a lot like Ansible. I use Ansible to manage my backup server running Linux on top of ZFS mass storage with zraid. Anytime I need to putz with it I gotta relearn the Ansible model again. The knowledge fades without constant exposure.

The color picker is working real nice now. Now I have to get to the tougher stuff.

-Dale

[wsu-cb]

I think it's fine to build them yourself until we figure it out. That's what I was doing. I've found that GitHub actions are mega-powerful but they can be as clear as mud when it comes to figuring them out. It's a declarative language.

My impression of declarative languages, based on GNU make and Yocto recipes: For simple things, they make things simpler. For complicated things, they makes things more complicated. Overall, I think I prefer procedural systems, but I guess we don't get to make that decision here.

The color picker is working real nice now.

Congratulations.

Now I have to get to the tougher stuff.

https://libquotes.com/lois-mcmaster-bujold/quote/lbn5o8y

[DLLarson]

Nice Quote! and oh...how so true.

[wsu-cb]

I have been working on a draft pre-release at https://github.com/CyberBoardPBEM/cbwindows/releases/edit/untagged-1cbf94f8eea40c2a4204. I started by looking at the release for v3.5-prerelease-3, but I have some issues to discuss:

1. I am currently calling the version 4.0-alpha.4+a4350fb and then appending a descriptor like .64bit.debug to describe the build variants. That doesn't match your previous names. Does that bother you?
2. Should we create a branch for 4.0 updates? I think we should eventually, but not yet.
3. Should I create the tag explicitly locally and then push it, or should we let Github do it automatically (which is how the draft is currently set)?
4. I don't really see a reason to provide the .pdb files. Anyone who understands Windows development well enough to use .pdb files can do the build themself. Can we leave them out?

[DLLarson]

(1)...That doesn't match your previous names. Does that bother you?

Nope. I trust you to create a better scheme. I'm not wed to mine. My only suggestion would be to name them in such a way that can those names can be automated.

(2) Should we create a branch for 4.0 updates? I think we should eventually, but not yet

I would say not until the moment an official release happens. Then it should exist so fixes can happen to the release code without worrying about including incomplete features from master. Of course master will also have the fix applied.

(3) Should I create the tag explicitly locally and then push it, or should we let Github do it automatically (which is how the draft is currently set)?

I'm not really sure. So long as the end result is the same I don't think it matters. But whatever will be supported best when the process automated should be considered.

(4) I don't really see a reason to provide the .pdb files. Anyone who understands Windows development well enough to use .pdb files can do the build themself. Can we leave them out?

Sure. None the PDB's are required. But I think offering the debug executables is desirable because they contain sanity asserts--but they can be a separate package. I don't think the debug version should be created for the final release though. These are just my opinions and I'm won't cling to them if they get in the way. It just seems like during betas the asserts and such used to detect inconsistencies would have the most value to ensure busted output files aren't created.

-Dale

[wsu-cb]

(1)...That doesn't match your previous names. Does that bother you?

Nope. I trust you to create a better scheme. I'm not wed to mine. My only suggestion would be to name them in such a way that can those names can be automated.

If I were writing a Linux shell script, I think it would be easy to generate this. In the context of Github actions, I have no idea.

(2) Should we create a branch for 4.0 updates? I think we should eventually, but not yet

I would say not until the moment an official release happens. Then it should exist so fixes can happen to the release code without worrying about including incomplete features from master. Of course master will also have the fix applied.

That's pretty close to what I was thinking.

(3) Should I create the tag explicitly locally and then push it, or should we let Github do it automatically (which is how the draft is currently set)?

I'm not really sure. So long as the end result is the same I don't think it matters. But whatever will be supported best when the process automated should be considered.

As in (1), I have no idea what is practical to automate.

(4) I don't really see a reason to provide the .pdb files. Anyone who understands Windows development well enough to use .pdb files can do the build themself. Can we leave them out?

Sure. None the PDB's are required. But I think offering the debug executables is desirable because they contain sanity asserts--but they can be a separate package. I don't think the debug version should be created for the final release though. These are just my opinions and I'm won't cling to them if they get in the way. It just seems like during betas the asserts and such used to detect inconsistencies would have the most value to ensure busted output files aren't created.

My view is that both beta and release builds should generate both debug and release executables. The docs should encourage downloading debug executables for beta releases, and release executables for releases. In other words, during the test phase, the sanity checking should be prioritized, but for a release performance should be prioritized. However, I think we should provide both variants. I can easily imagine asking a user to run a debug build to check for any asserts if the user reports a difficult-to-reproduce bug.

[DLLarson]

If I were writing a Linux shell script, I think it would be easy to generate this. In the context of Github actions, I have no idea.

Then don't worry about for now. It's minor in the scheme of things. I'm sure GitHub actions can handle most what we through at it. It's not lightweight--which is part of the problem of just walking up and using it.

As in (1), I have no idea what is practical to automate.

Ditto my previous comment.

That's pretty close to what I was thinking.

Lets go with that then.

My view is that both beta and release builds should generate both debug and release executables.

Then let's do that then. Not a problem.

An aside... I may have a way to do the integer scaling without touching the low level rendering stuff by simply scaling up the resulting memory DC used to render the boards. Here's a taste of where I'm at (I'm only working on CBDesign at the moment to test my ideas):

Note that I haven't addressed the tile/marker/piece trays yet.

-Dale

[wsu-cb]

Another question: Do we really need to upload .zip/.tar.gz files of the source code? The release should specify the git commit id and/or corresponding tag, so users that want source code can download a .zip using the "Code" button on https://github.com/CyberBoardPBEM/cbwindows or the corresponding button for a particular commit id.

[DLLarson]

Do we really need to upload .zip/.tar.gz files of the source code?

Nope... For a couple reasons. It's not GPL'ed so there is no requirement to supply source (a big reason I avoided it). Just the same, the astute person could just obtain the source using the SHA git ID or they could use the release's tag.

-Dale