WiX3.14 release binaries contain incorrect file versions

oleg-shilo commented 6 months ago

WiX Version

3.14.0.8606

.NET or MSBuild or Visual Studio Version

n/a as it is a packaging problem

HeatWave Version

n/a

Windows Version

n/a

Repro Repo

n/a

Repro Steps

The release https://github.com/wixtoolset/wix3/releases/tag/wix314rtm contains binaries (e.g. melt.exe) stamped as inconsistent versions: File: v3.14.8606.0 Assembly: v3.14.0.8606

Probably just a typo.

And the next release v3.14.1.8722 has similar problem:

Actual Result

File: v3.14.8606.0 Assembly: v3.14.0.8606

Expected Result

File: v3.14.0.8606 Assembly: v3.14.0.8606

Acknowledgements

[X] I acknowledge that this is a fully completed bug report. It is not a question or attempt to get help debugging my issue (because those should be sent to Discussions).

barnson commented 6 months ago

It's weird but not incorrect. It was an intentional choice in v3.x.

oleg-shilo commented 6 months ago

LOL, so it was an "intentionally weird choice" Anyway, it cannot be fixed. The release is out there anyway. I just wanted to let your team know about the problem so it is corrected in the very next release. But... does it mean that by closing this issue you are going to maintain this weird versioning schema? Or it's going to be addressed and done the same normal way as it was in all WiX historical releases?

robmen commented 6 months ago

In the latest WiX meeting, as we triaged this issue, I challenged everyone to consider why versioning in v3 was done this particular way. There is a very specific, technical reason. We'll see at the next meeting if anyone figures out.

oleg-shilo commented 6 months ago

I challenged everyone to consider...

Good on you, Rob. Good luck with getting it sorted.

robmen commented 6 months ago

Good luck with getting it sorted.

Thanks, but as Bob pointed out above, there is nothing to sort out. It's working as designed.

While I have you here, @oleg-shilo , I read your comments in the linked issue above.

Please stop disparaging us and this project.

Your comments do not demonstrate that you want to work constructively with us. Your comments are particularly damaging when you make incorrect assumptions about our decisions and goals that misrepresent what we actually do here.

I know you edited away the worst comments on that thread, but the initial comment is the one sent out via email to everyone who follows the Issues in your project. If you edit away your incorrect statements instead of posting follow-up comments correcting your incorrect assumptions, passive watchers of your project can be misled.

Consider what sort of relationship you want with us in the WiX project as you make comments going forward.

Thanks.

oleg-shilo commented 6 months ago

Rob, my intention is not to "disparage you" but to help my users and, if possible, to maintain a constructive relationship with WiX team.

In the case that you are referring to I responded to the user request and explained to him what exactly was happening with the problem he was experiencing.

I had no intention of taking the blame for the mistakes of WiX team (I can make my own mistakes for that :o) ) that's why I explained what exactly is the cause of the problem (as I see it) and what are the chances of fixing it or getting support from WiX team. If you disagreed and wanted to correct me you were welcome to participate in that discussion.

For anyone who reads this, in my post I expressed my disappointment with WiX team being very defensive when it comes to handling defect reports. And brought examples of that, including this very issue #8080. And also not always recognizing the urgency of some defects that are impacting sometimes ALL users.

Even though I did not distort any facts and was fully accurate, I decided to change the post and make WiX team to look a little better. So I edited the post ~1-2 minutes after I posted it the first time. I regret now that I edited it. I should have let it as it was. It is clear to me that you are still super defensive and nothing changed.

Even this there is nothing to sort out. is a clear indication of that. Guess what, most likely you will find the cause of the problem and will start stamping the assemblies with the same assembly version and file version as you did before that release. So most likely it will be "sorted out" :)

Unless of course, you decide to preserve the status quo and keep the defect just to prove the point.

Anyway, it's clear to me that "constructive relationship with WiX team" is rather problematic for me so I will remove myself from it and from now on will redirect my users to your site and ask them to do the defect reports.

I am not going to participate in any discussion of this matter any further so I am not going to respond here any more.

I still wish your project the success it deserves. Cheers

robmen commented 6 months ago

Oleg has made it clear he will no longer respond to this thread, which is completely respectable. So, I'll refer to him in the third person as I close the loop on this issue.

First, I want to capture his original edit that I referred to in a previous comment for future reference (just in case GitHub loses it for some reason):

The root problem is that in his comment (as captured in the image and commendably consistent in his comments above), Oleg refuses to accept that these version numbers are different for specific reasons. What he views as "super defensive" communication is simply frustration.

Ultimately, I think his idea to direct users here to open issues in the WiX Toolset is fantastic. This way, he can simply redirect users here and he no longer needs to make assumptions about our actions. I look forward to interacting directly with those bug reports.

wixtoolset / issues