search

AdamsLair / duality

a 2D Game Development Framework
https://adamslair.github.io/duality
MIT License
1.4k stars 291 forks source link

Duality v4.0 Release Schedule #820

Open ilexp opened 4 years ago

ilexp commented 4 years ago

Summary

This is an aggregate issue to reflect what still needs to be done before Duality v4.0 can be released, intended to roughly list points that did not make it into their own issues yet. Some of these points may already be done partially or fully and are listed to verify their current state.

The intent of this is to answer and evolve the question "where are we on this?", and act as an internal roadmap and discussion platform for v4.0.

Analysis

Feel free to move any of those into their own separate milestone issue, then comment here with an updated list that links to it, or crosses it off.

Barsonax commented 4 years ago

Consider adding an automated .zip pack step in some .csproj, like it was done for the now obsolete embedded GamePluginTemplate, so it doesn't need to be zipped manually for release.

I think it would be best to make a separate project for this in the solution. Maybe in the future we might add more involved build steps here (dotnet new template etc?) so better to keep it separate.

Do some extended testing with the template to make sure everything works and is reasonably polished.

Yeah 100% agree we should test this thoroughly and involve the community in this as well. They might give us some usability feedback as well.

Consider to also do and bundle any other (breaking) changes that would require a major version step, preferably those that would benefit from the netstandard 2.0 / C# 7.3 upgrade.

Agree, this will help reduce the amount of breaking releases we will do in the future.

Eventually, when all is tested and done, bump all package versions to 4.0 and merge into release.

Easiest is to just do a string replace. All versions are already set to 4.0.0-alpha anyway so this is really easy and fast to do.

SirePi commented 4 years ago

Totally agree. There's a bunch of issues I saw around that should be easy to tackle if I'm not mistaken.. I will make a list and see what you think about the eventual priorities

EDIT: I believe these 4 are simple enough to warrant a quick fix without delaying too much v4

784

779

763 (have to understand how tilemaps work first)

748 (if it's as it is explained)

SirePi commented 4 years ago

Oh, and don't forget to bring any new v.3 fix in v.4's branch

Barsonax commented 4 years ago

Move the DualityProjectTemplate that we'll bundle in the download .zip to somewhere inside this repo.

Made a issue for this: https://github.com/AdamsLair/duality/issues/824

ilexp commented 4 years ago

Updated the generic download link (https://get.duality2d.net/) that is used on the website and potentially everywhere else from redirecting to the v3 download to this:

https://github.com/AdamsLair/duality/releases/latest/download/Duality.zip

which will always redirect to the latest release on the GitHub repo. Only requirement for it to work is that the attached binary zip is called Duality.zip.

Barsonax commented 4 years ago

With the template PR #825 merged I believe it is now possible to do a actual alpha/beta release of duality 4.0.0.

If we want we could invite some users to test it out. Also we could upload the dotnet new template pack to nuget so that we can test that as well.

The docs still need more updates though but thats not directly blocking for releasing a prerelease

ilexp commented 4 years ago

Checked out the latest commits, looks pretty good.

One thing I noticed though is that the current template is a bit confusing: When I extract the .zip, I get a directory build props file and a Source subfolder, leaving me a bit stumped. Can we move the solution file to the root folder? That way, it will provide a clear installation hint to new users:

Without the .sln, that installation flow is less intuitive, because you have to (albeit very briefly) start digging to discover it. This one thing is what I'd address before the alpha release - other than that I'm totally giving this a go 👍 Really looking forward to this.

Given the current CI and branching scheme, releasing that alpha build (by bumping all versions accordingly and merging into release) will mean losing the ability to easily (without manual intervention) release further v3.x packages. This is not great, but given that we don't have any critical bugs or pending hotfixes there right now, it should be manageable.

On that note, I don't think we ever tested the NightlyBuilder with pre-release versions. Just to be sure, before merging into release, please do a full local re/build and then locally run the Build\Scripts\Package Binary CI Script.bat script on your machine first, and ensure all packages are built as expected.

Also we could upload the dotnet new template pack to nuget so that we can test that as well.

Can we flag that one as alpha as well? If yes, then I'm all for it 👍

Since this is a first time package upload, we'll need to set up AdamsLair organization ownership on NuGet. Feel free to upload one yourself, but please transfer ownership to AdamsLair and AdamsLairBot afterwards. I should get an e-mail automatically to confirm the transfer and will know what's up.

For the future, the CI build should pick up on the project and release the package as well. One way to achieve this would be to add a .nuspec to the Build/NuGetPackageSpecs folder, in which case the NightlyBuilder will pick it up. Alternatively, you can configure the project so that a regular build will create a .nupkg that ends up in Build\NightlyBuild\NuGetPackages, which is where the CI script gathers build artifacts.

Edit: Oh, and one more thing. Even if that's just for my personal peace of mind, after the v4.0-alpha pre-release, please do a brief test whether the existing v3.x binary release still works with a fresh install + DualStickSpaceShooter via builtin package manager. I know you tested this locally and you're 100% sure it works in the real world case, and I honestly believe you, but I also know that there were situations where I have been 100% sure in the past and was still wrong 😄 So on the off chance that something goes wrong, at least we know it and can act accordingly. (Feel free to ping me as much as you want in that case.)

Barsonax commented 4 years ago

Without the .sln, that installation flow is less intuitive, because you have to (albeit very briefly) start digging to discover it. This one thing is what I'd address before the alpha release - other than that I'm totally giving this a go 👍 Really looking forward to this.

Makes sense, I just put it in source as all source files are there but having the sln in the root does make commandline usage easier (can just run dotnet build from the root without any path). DONE

On that note, I don't think we ever tested the NightlyBuilder with pre-release versions. Just to be sure, before merging into release, please do a full local re/build and then locally run the Build\Scripts\Package Binary CI Script.bat script on your machine first, and ensure all packages are built as expected.

We have been testing locally with 4.0.0-alpha for a while now on master and seems to work just fine after I fixed it in https://github.com/AdamsLair/duality/commit/7af3efcd75ceb873bf5243e6656b1911a3f66b11

Can we flag that one as alpha as well? If yes, then I'm all for it 👍

Ofcourse in the end its just another nuget package. In fact at this moment it uses 4.0.0-alpha as the version.

For the future, the CI build should pick up on the project and release the package as well. One way to achieve this would be to add a .nuspec to the Build/NuGetPackageSpecs folder, in which case the NightlyBuilder will pick it up. Alternatively, you can configure the project so that a regular build will create a .nupkg that ends up in Build\NightlyBuild\NuGetPackages, which is where the CI script gathers build artifacts.

I can turn generate package on build on and let it output to Build\NightlyBuild\NuGetPackages. Its the easiest way to do it. DONE

Oh, and one more thing. Even if that's just for my personal peace of mind, after the v4.0-alpha pre-release, please do a brief test whether the existing v3.x binary release still works with a fresh install + DualStickSpaceShooter via builtin package manager.

Since the 3.x package manager completely ignores prerelease packages anyway its not even possible to install 4.0.0-alpha even if you really wanted to :P. This is one of the features we gain in 4.0.0 since we are now able to install prerelease packages as well if we want it.

ilexp commented 4 years ago

Makes sense, I just put it in source as all source files are there but having the sln in the root does make commandline usage easier (can just run dotnet build from the root without any path). DONE

Ah, that's super neat as well 👍

I can turn generate package on build on and let it output to Build\NightlyBuild\NuGetPackages. Its the easiest way to do it. DONE

Great, that means the release can now take place with the regular "merge master into release" mechanism 🙂

I think we're all set then. I'm going to keep myself in the background for the alpha release stuff, proceed as you see fit. If you want, we can set a date and time for it where I'm available as a backup just in case something in the CI or so acts up, but I'd leave this to you guys.

Barsonax commented 4 years ago

With https://github.com/AdamsLair/duality/pull/852 merged the last thing to do is to think of better naming for the settings (while at it we might also do some improvements to the settings) in https://github.com/AdamsLair/duality/issues/855. Since this will potentially break projects we should do it before releasing 4.0.

After this we can do another alpha release, test it and when we find it satisfactory start a beta where other ppl of the community can try out duality.

ilexp commented 4 years ago

Sounds good 👍

Edit: Oh, but we definitely need to address #799 before going beta.

ilexp commented 3 years ago

As a general note, while doing some tests reviewing and merging #878, I found a few previously unnoticed issues, such as the new launcher never loading the starting scene or the lack of any quickly usable testing environment for core devs.

Them going unnoticed despite their impact highlights the lack of a closed dev loop and user feedback right now, so for practical, QA and safety reasons, I honestly think v4.0 should not leave the alpha preview state until that changes. Small steps until then.