NUnit downloadable packages zip file naming is confusing and non-intuitive about nunit-distribution

[ChrisMaddock]

@nunit/core-team

I agree this is ambiguous. I know we tried when we split things up to not change the package names, but I think that would be preferable to having same-named packages with entirely different contents.

I propose we rename the msi and zip to NUnit.Console, to match the nuget package. I'd also like to rename the framework zip to NUnit.Framework.zip - to avoid any ambiguity. Thoughts?

[rprouse]

I am good with renaming both. At a minimum rename the console ZIP and MSI

[CharliePoole]

Additionally, it looks like you reused the guid from the old framework plus console here. Different packages should have different guids.

[ChrisMaddock]

@CharliePoole Which guid are you referring to, the msi 'upgrade code'? We can change it, but I thought we wanted it to be an in place upgrade, and just lose the framework for 3.0.

[CharliePoole]

I guess we never discussed how we wanted it to work - probably should have.

I haven't used the msi installer myself for a long time, but I used to do it all the time with V2. I was able to have as many versions of it as I wanted on my machine because they each installed to a different directory. With 3.0, we decided to use a common directory but I always assumed you could still do it by changing the directory for the install. Seems like you can't.

In V2, I changed the Product Id guid for each release but not the UpgradeCode. Is that what you still do? If so, maybe the Microsoft Installer has changed, since it won't even run the install for me if I have a newer version installed. With V2 I could do that in order to check out a bug.

In any case, what I'm really asking here is this: If we give this a different name (NUnit-Console) and the user downloads it from the nunit-console project and not the nunit project, does it make sense for it to have the same upgrade code? How will it work for users in each case? I think this is something we should decide for 3.6, when the naming is changed.

[ChrisMaddock]

I'd forgotten the v2 installers worked like that. :-) The different directory paths were why we spent a few years fixed at 2.5.7, because changing the exe path everywhere we referenced it was a chunk of work!

Sounds like the GUID changes remain the same: currently the product ID is unique per build, the UpdgradeCode doesn't change. There's defined functionality to prevent downgrading. I don't know how this differed to the v2 installer internally, I never saw it.

In terms of how it should work - I think this is good behaviour! The console is built such that it can run any v2/3.x framework, so as far as I can imagine, needing multiple versions installed side by side will only ever be a developer problem which can be worked around with nuget/the zip packages. Regarding removing the framework - I saw it more as dropping a highly underused component of the bundle, than as a 'new product'. Accordingly, an in-place upgrade still seems the right solution to me, from a usability point of view. A rename just better reflects the packages current contents, which we understand to be what people were using the bundle for anyway (based on the lack of complaints at the framework's removal!).

I'm aware these are mainly just my opinions/preferences, however! @nunit/core-team?