Duality v4.0 Release Schedule

[ilexp]

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

• Move the DualityProjectTemplate that we'll bundle in the download .zip to somewhere inside this repo.
  • 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.
  • Remove the now obsolete "package .zip" build step from NightlyBuilder.
• Do some extended testing with the template to make sure everything works and is reasonably polished.
  • Consider releasing a set of 4.0-beta pre-release packages and a 4.0-beta download .zip that can be used by developers and the community early adopters for testing prior to release.
• Update the download link subdomain to always point to the latest release download, see here.
• Add a v4 docs folder including any required page updates and a new changelog page, see issue Write guidelines on how to switch to the new v4 template #799 for that.
• 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.
  • We don't have an issue for that yet, but RawList<T> for example could use an API upgrade with a ref-return indexer, and so on.
  • Nothing specific required here, but it would be a good opportunity. Also, this should probably be in beta for a while, and if we're waiting for release anyway, why not do something useful with the time 😄
• Eventually, when all is tested and done, bump all package versions to 4.0 and merge into release.
  • Might have to update the version updater behavior to deal with previous pre-release beta versions properly when used with ApplyGlobalUpdate=Major as a command line parameter. Right now, it doesn't really support pre-release versions or considers them at all.
  • Alternatively, just do it manually - it's "all packages or none" anyway.

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]

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]

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]

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

[Barsonax]

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

Made a issue for this: #824

[ilexp]

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]

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]

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:

• Got a .zip - let's extract that.
• Ah, there's a .sln - let's build that.
• Oh, there's binaries now and two "launcher" projects - let's run that.

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]

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 7af3efc

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]

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]

With #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 #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]

Sounds good 👍

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

[ilexp]

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.