Versioning

[bdukes]

@valadas We'll need to bump the version of this project in order for it to upgrade in the next release of DNN Platform. Does your GitHub Actions versioning magic have something to help that scenario?

[bdukes]

7c2024d3a56988fc8a94e67450d713b58b2f0bd6 is an example of a commit that bumps the version, FYI

[valadas]

Well, I have an action that can fetch the latest non-rc version number from Dnn repository (or any other if specified repo/owner) https://github.com/valadas/dnn-platform-get-version but that would get the previous version, since we decide on versions at the time of RC creation, that may not be the solution...

I also have a action that can pull the version number out of a release/x.x.x branch name https://github.com/valadas/get-release-branch-version That would allow to create a release/x.x.x branch to fire up some automation like setting manifest versions using https://github.com/valadas/set-dnn-manifest-versions

I also have a bunch of other actions, but the main problem is on Platform we want to decide the version just at release time, and also we use the develop branch from here.

So I see 2 possible solutions;

1. We move this repo to the main one and follow the rest of our versioning logic there and also gain by having the issue management together and single PRs for changes that affect both this repo and Platform (like DI stuff happening now, etc.). And we get to not forget to mention changes here in Platform release notes, etc.
2. We use some branching strategy here where development happens on develop, we use a release/x.x.x automation to manage versioning and merge to master before Dnn release, then we adjust Platform to pull from master instead of develop at the releaes time build.
3. Well, current state is all manually managing this as it is done now.

[bdukes]

@mitchelsellers @donker any thoughts? I think it would make sense to version this along with DNN Platform, I'm on the fence about moving it into the main repository.

I'm trying to decide if creating a release/1.1.1 branch to get automated version bumps is easier than just manually bumping those couple of files to 1.1.1. It's probably not worth it, unless it brings this more in-line with other repos that are setup this way.

[valadas]

Another option can be in Platform build scripts to just bump the manifest versions to match Dnn, but then it makes it very hard to know which PR got into which version...

IMO this is the default html editor that comes with Platform and it belongs on it's repository, That would not prevent anyone to replace it with something else or exclude it from a custom distribution install and I see no reason why not do it... Opinions ?

[mitchelsellers]

I’ve been on the fence for a long time. But I’m at the point of agreeing with @valadas on this.

We cannot deploy DNN Platform Releases without this. And We maintain the whole code. It most likely “should” be in the project and versioned as such.

[bdukes]

Works for me

[bdukes]

I've started that merge at https://github.com/dnnsoftware/Dnn.Platform/pull/4096. I'm not sure what pieces in the build need to be adjusted. I'm sure, at least, we need to add its project to the main solution file, but there's probably pieces in Cake that need to be adjusted also.

[valadas]

Yep, we will need to adjust the build to remove pulling the development branch for here and include this in the normal build. Glad we came to an agreement on this one 😄

[valadas]

Ok, I went though all the issues here and closed or moved them as appropriate.

What's left:

[X] We need a second approval/merge on https://github.com/dnnsoftware/Dnn.Platform/pull/4096 [X] Adjust the build in Platform to build this module like the other ones https://github.com/dnnsoftware/Dnn.Platform/pull/4105/files [ ] Adjust our Azure pipeline to no longer fetch this repository (I think actually the fetch is done on the build scripts but we need to remove that setting if it no longer does anything.