Improve/Add Build Automation including nuget packages for dev branch

[gismofx]

As Suggested by @SeanFeldman

Would be nice to have automation in place to build the package from master as well as a manual kicked off the pipeline to build preview packages for occasions such as this.

This will help with, for example, field-testing fixes made to dev branch by just using a nuget to test with rather than requiring an individual to fork and build from source

[SeanFeldman]

@gismofx where's Toast-Blazor-Calendar-600.png is coming from? It looks like it's not checked in.

[SeanFeldman]

I'm going to add it in the PR I'll raise.

[SeanFeldman]

@gismofx have a look at the changes I'm proposing in #41.
Once those are in place, I'll move on to GitHub actions to set up the CI/CD pipeline.

[SeanFeldman]

With #41 out of the way, a package is generated on Release and Debug builds, on any branch.
MinVer is used to control the package version (using tagging) and will be leveraged to push to NuGet.

@gismofx, I'll be looking into automation of the CI/CD. There will be certain things I can't do on the repo as I'm not a collaborator (specify secrets such as NuGet key, create and modify GitHub Actions, etc.). There are two options:

1. I do it on a fork and we transition it here after
2. You grant me a temporary collaborator access

Whichever works better for you.

[gismofx]

@SeanFeldman I'm fine making you a collaborator. This is probably easier. I'll work on that now.

I just want to know what/how things work and what we are changing. Maybe we document it here in the issue discussion for posterity? I'm open to other ideas too. Maybe a GitHub project?

[SeanFeldman]

Thank you.

The proposed changes are (we can discuss various options):

1. Introduce CI/CD that compiles, tests, and deploys the package automatically from the main branch when it's tagged. Currently, there are no automated tests but it will be an option to add later.
2. Deployment from feature branches to NuGet with a manual request (tagging)

[gismofx]

Thank you.

The proposed changes are (we can discuss various options):

1. Introduce CI/CD that compiles, tests, and deploys the package automatically from the main branch when it's tagged. Currently, there are no automated tests but it will be an option to add later.
2. Deployment from feature branches to NuGet with a manual request (tagging)

This sounds good. I've been planning to add some tests at some point, so would be good to know how to get that connected up.

[SeanFeldman]

Quick update - have not forgotten about this. On vacation till early August 🙂

[gismofx]

Quick update - have not forgotten about this. On vacation till early August 🙂

No worries. Thanks for the update. Enjoy vacation!

[gismofx]

Hi @SeanFeldman do you have an update on this feature?

[gismofx]

Hi @SeanFeldman do you have an update on this feature?

@SeanFeldman Any time to work on this?

[SeanFeldman]

So sorry. I started looking at it, and work took over my time.
I still want to automate the process. Maybe let's specify smaller concrete deliverables as a checklist I can work against?
And yes, I need reminders 😀

[gismofx]

So sorry. I started looking at it, and work took over my time. I still want to automate the process. Maybe let's specify smaller concrete deliverables as a checklist I can work against? And yes, I need reminders 😀
@SeanFeldman

Thanks. That's ok. I'm not sure what all of the concrete steps are... need some input from you. How about a kanban board/project I've created one and linked it. Are you able to edit it?

The first thing I'm thinking would be it's setup so we can manually build the project and the version numbers are correctly set. I'm happy to manually upload a nuget package for the time being. Or maybe just some instructions on how to do it manually?

For example, I made one change and number applied is lower than the manual version I created and Nuget treats it as previous version:

[SeanFeldman]

The first thing I'm thinking would be it's setup so we can manually build the project and the version numbers are correctly set.

That should be a good starting point, agreed.

I do have a question about the versioning scheme you have there. It feels a little weird. You've got 1.0.0-beta1.1.59. The 1.1.59 part, which feels like a version on top of a version. Wouldn't it be more accurate to express it as a 1.0.0-betaXXXX where XXXX is a running counter, like the number of commits from the 1.0.0-beta ? Take, for example Newtonsoft.Json, you want the latest betas to be on top.

[gismofx]

Great! This helps explain the 1.1.59

That 1.1.59 came from the new versioning system and don't know how to control that :); I don't know how to use it. But I ran with it to get the update out to nuget.

How can we bump it up to beta 4.x?

[SeanFeldman]

What is beta 4.x? Does that mean the version is 4.0.0-betaxxxx? Or the version you want to have 1.0.0-betaXXXX?
Let's establish what's the version is first and then what the preview/beta counter means to you.

The way I understand SemVer, a version is always MAJOR.MINOR.PATCH no matter if it's a preview/beta or not.
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format. From the document linked:

Precedence for two pre-release versions with the same major, minor, and patch version MUST be determined by comparing each dot separated identifier from left to right until a difference is found as follows:

1. Identifiers consisting of only digits are compared numerically.
2. Identifiers with letters or hyphens are compared lexically in ASCII sort order.
3. Numeric identifiers always have lower precedence than non-numeric identifiers.
4. A larger set of pre-release fields has a higher precedence than a smaller set, if all of the preceding identifiers are equal.

Example: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0.

[gismofx]

I think my intent is inline with SemVer Major.Minor.Patch-Beta-XXX

Current version is still 1.0.0 then we're just working on beta versions..The beta numbers I was using was sort of like an internal SemVer, which would visually indicate the type of change between betas. I.e Major.Minor.Patch-BetaMajor.BetaMinor

Is this practical?

I'm open to changing it for sake of clarity; where XXX could just be incremental build number as you suggest.

[SeanFeldman]

Got it. Yeah, following the Major.Minor.Patch-Beta-XXX pattern is gonna be more mainstream and clear. Also, getting a version out of the repo will be very simple as XXX will be always commits height (number) from the last stable version. So if you release 1.0.0 (stable), the next beta would be 2.0.0-beta1. And then 2.0.0-beta2, etc. Until 2.0.0 stable is released. For minors and patches, it would be the same model. The stable version stamping would be done by tagging.

If you are OK with that approach, I could try it.

[gismofx]

This sounds good.
I assume we could still make incremental updates to the 1.X.X stable version?

[SeanFeldman]

I assume we could still make incremental updates to the 1.X.X stable version?

Correct.

[SeanFeldman]

@gismofx, you've got both, dev and main. I'm wondering if that's necessary. In the end, if I understand correctly, main is what you release. Feature branches can be created and merged into main with the need of the staging dev branch. Any specific reason I'm missing for dev to exist?

Asking as I'm thinking that the versioning will work much smoother with Release Flow.

[gismofx]

@SeanFeldman The article was a good read and I think is probably inline with how this repo should work.

The intent was to develop features and fixes on dev and then push into main. If someone wanted to try the changes on dev, they could just checkout/fork the dev branch. My intent was to be able to publish a nuget of the dev branch.

Talking/thinking this through, and correct me if I've misunderstood, I think it makes sense to just publish main as release version on nuget. Then, any "dev" or "feature" commits could be tagged with pre-release versions and a pre-release nuget would be published. All the while, always committing the dev branches to main, just appropriately tagging the merges? (I hope I'm not confusing things). (The one thing was preventing regressions if we're making hot-fixes while developing new features. I suppose code-review and merge tools should help to identify any issues)

From the article which I think makes sense:

[SeanFeldman]

That's exactly the idea, @gismofx.
As I was going through the change that needs to take place, it became apparent that the dev branch is unnecessary and it would be simpler to work w/o it. Release from main could be both, stable (if verified and approved) and pre-release (while work is still in progress or there's no intent to release a stable yet). And the decision wherever it is one or another is manually controlled. Which is likely the case.

So if you agree, I'll work with the assumption that main is the branch and dev is no longer necessary.

[gismofx]

Yea, I agree.

In other words, I will develop on some branch(probably dev), merge into main, and then make releases from main, either release or pre-release.

[SeanFeldman]

Precisely. Thank you for the quick response. Unlike my tortoise speed 😂

[gismofx]

@SeanFeldman Little poke :)

[SeanFeldman]

My bad, @gismofx. I'm so swamped at the moment that won't be able to do anything for the next 2-3 weeks. But please keep poking me!

[SeanFeldman]

I've been bad about this 😃
I am finally getting some air to breathe and look at anything other than work-related stuff.
@gismofx, are you still actively maintaining this project?

[gismofx]

Hey! Thanks for checking back in! I am still using this project. Haven't pushed any changes recently; I've been somewhat holding off for the build automation stuff. Also, I have a few other projects I'd like to leverage this on too.