Release by GitAction

[Nice3point]

Summary of the Pull Request

What is this about:
Automatic release creation

Description:
Chenzhlog is automatically picked up from here https://github.com/jeremytammik/RevitLookup/blob/dev/Doc/Changelog.md

The version is picked up from here https://github.com/jeremytammik/RevitLookup/blob/dev/RevitLookup/RevitLookup.csproj#L8

The release will not be generated if there is an existing one with the same version. The feature is enabled for the master branch. For everyone else, the project will simply compile to check pull requests

Now the version style will be as follows:

• Dll version - 2022.0.2.5
• Installer name - 2022.0.2.5
• Installer version - 22.0.2.5 (displayed only in the control panel and used for updates)

Quality Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have made corresponding changes to the documentation
• My changes generate no new warnings

[Nice3point]

@ricaun see the changes, maybe you have your own vision 😉
Build/Build.GitHubRelease.cs file with new feature

[Nice3point]

@ricaun the major version of the installer must be up to 255. 2022 does not fall into this range. Therefore, the version number of the installer will be 22.0.0.0, and the file name will be 2022.0.0.0 (as well as the dll version). I did it so as not to break the current versioning, as requested by Jeremy

[Nice3point]

@ricaun i fixed this part of the code 307a054

[ricaun]

@ricaun the major version of the installer must be up to 255. 2022 does not fall into this range. Therefore, the version number of the installer will be 22.0.0.0, and the file name will be 2022.0.0.0 (as well as the dll version). I did it so as not to break the current versioning, as requested by Jeremy

This is an installer(msi) limitation, right? =(

[Nice3point]

@ricaun yes it is Windows standard https://docs.microsoft.com/en-us/windows/win32/msi/productversion

[ricaun]

@ricaun yes it is Windows standard https://docs.microsoft.com/en-us/windows/win32/msi/productversion

I only use .exe and does not have this 255 limitation... This is annoying.

[Nice3point]

Any more suggestions? mb add logging of some more code fragments? if not i merge the branches

[ricaun]

maybe Microsoft will remove this limitation sometime) now the version style will be as follows: dll version - 2022.0.2.5 installer name - 2022.0.2.5 installer version - 22.0.2.5 (displayed only in the control panel and used for updates)

Maybe without the 20 was fine all along, and only add 20 on the release tag. To make the DLL installer name and installer version the same number. This gonna make the code much simpler.

[Nice3point]

I only use .exe and does not have this 255 limitation... This is annoying.

is your option of creating an exe installer a manual creation of a configuration file? WixSharp does it automatically, so far I haven't seen a better way)

[ricaun]

I only use .exe and does not have this 255 limitation... This is annoying.

is your option of creating an exe installer a manual creation of a configuration file? WixSharp does it automatically, so far I haven't seen a better way)

Only manual creation using Inno Setup, WixSharp is great to automate the installer creation.

In the end, does not matter too much, the end-user never gonna notice if the DLL version is 2022 or 22.

[Nice3point]

Maybe without the 20 was fine all along, and only add 20 on the release tag. To make the DLL installer name and installer version the same number. This gonna make the code much simpler.

I didn't quite understand how 20 will simplify the code, can you show an example? or send a PR to the dev branch? in the method that searches for the productversion of the dll file, I trim the extra digits to conform to the microsoft standard. And when I form the name of the file, I return them back. Maybe just substitute the original version in the file name and not combine 20 with the cropped part

[Nice3point]

@ricaun

did this:

var version = GetAssemblyVersion(args, out var dllVersion);
var outFileNameBuilder = new StringBuilder().Append(OutputName).Append("-").Append(dllVersion);

in out I get the original version of the dll file

[ricaun]

@ricaun

did this:

var version = GetAssemblyVersion(args, out var dllVersion);
var outFileNameBuilder = new StringBuilder().Append(OutputName).Append("-").Append(dllVersion);

in out I get the original version of the dll file

In my point of view, you are over-engineering 😄

https://github.com/ricaun/RevitLookup/blob/e039e0224b8a77628b86ec0be8cde86a2d8771a6/Build/Build.GitHubRelease.cs#L38

https://github.com/ricaun/RevitLookup/blob/e039e0224b8a77628b86ec0be8cde86a2d8771a6/Installer/Installer.cs#L86-L97

And the version of the DLL stay like 22.0.2.6

[Nice3point]

And the version of the DLL stay like 22.0.2.6

the whole point was to, if possible, leave the 2022 version of the version where possible) there is no limitation in the version for dll)

[ricaun]

And the version of the DLL stay like 22.0.2.6

the whole point was to, if possible, leave the 2022 version of the version where possible) there is no limitation in the version for dll)

Yes I know but why change.?

[Nice3point]

The release is being formed perfectly) I also cut off the extra text from the changelog

[Nice3point]

Yes I know but why change.?

The version was originally 2022, which I changed to 22 when I added the build system. Now it turned out to return the old style of naming)

[ricaun]

Yes I know but why change.?

The version was originally 2022, which I changed to 22 when I added the build system. Now it turned out to return the old style of naming)

Perfect, I was thinking the original was 22 instead of 2022.

[ricaun]

Great work @Nice3point 👍

[Nice3point]

Thanks) You can add the signing of the msi file so that Windows SmartScreen does not throw a warning, at the same time you will practice with Nuke) I'll add these features to my templates later. And add options when creating

[Nice3point]

@jeremytammik Now changes to the master branch will create a new release. Or if it exists the pipeline will fail. Therefore, use the dev branch, and merge with master only if you think you need to create a new release. Also, before merging, you need to remember to update the changelog and upgrade the version😉

[jeremytammik]

okey-doke. impressive automation, very complete. wow. thank you, @Nice3point and @ricaun for all your enthusiasm and efforts! i wonder if this conversation and these many insights are of interest and use to other Revit add-in developers as well, and should be documened or summarised on the blog... what do you think?

[Nice3point]

I think not, this is just a convenience for the users. Developers should not touch this code, it is not related to the development of this plugin. The only rule is that you do not accept PR in the master branch. But I think it can be blocked by the YML file, I will do it later. All documentation is here https://github.com/jeremytammik/RevitLookup#installation And the information for you, as the owner of the repository, is in the description for this PR 😉

[jeremytammik]

brilliant, thank you very much! i wish you a good night and a pleasant sunday!

[Nice3point]

@jeremytammik Once again, I will repeat the steps that you must take to publish:

• Developers send PR to the dev branch.
• We check, write a code review.
• Accept PR.
• You are upgrading the build version here https://github.com/jeremytammik/RevitLookup/blob/dev/RevitLookup/RevitLookup.csproj#L8
• Make changes to the changelog https://github.com/jeremytammik/RevitLookup/blob/dev/Doc/Changelog.md (multiple lines are supported, the main thing is that the line does not start with a hyphen "-", it means the end of the description of the current release)
• Merge the dev branch into master.
• Release will be generated automatically

[Nice3point]

brilliant, thank you very much! i wish you a good night and a pleasant sunday!

And thank you too)