Conversation
We specify `7.*` instead of `7.0.*` because there is currently an open PR updating SIL.Chorus.Mercurial to version 7.2.2, and a `7.*` spec will allow downstream Chorus-using projects to smoothly update to version 7.2.2 of Mercurial later without requiring a new Chorus PR to be tested and approved.
|
I have downloaded the SIL.Chorus.Mercurial 7.0.1.58 NuGet package and run the Chorus unit tests against it, on both Linux and Windows. All tests pass. I have not yet built the Chorus installer and verified that it would work without changes in FLExBridge. That was a concern raised by @hahn-kev in sillsdev/Mercurial4Chorus#30 (review), so it's worth testing. (By someone who has a working setup to build the Chorus installer and test it with FLExBridge and FieldWorks, i.e. not me). |
|
Installer is failing because it cannot find certain files, which were actually unnecessary in our Chorus Mercurial package (they were part of TortoiseHg and Chorus never uses them) and which I therefore deliberately removed in version 7 of the Mercurial package. I'll go through and see about removing them from the installer, though someone with more experience with WiX may need to help me confirm that the installer will then properly remove them from a user's computer when upgrading from 6.5 to 7.0.1 (or 7.2.2). |
Seven files deleted between Mercurial 6.5.1 and 7.0.1, and one new file, which the installer needs to know about in order to build correctly.
|
In light of the failing installer build step (caused by the file list changing), we probably shouldn't just set |
|
sillsdev/Mercurial4Chorus#33 has been approved and is going to be merged soon, which will result in a new 7.0.1.xx NuGet package that will require SIL.BuildTasks 3.3. SIL.Chorus.Mercurial 7.0.1.58 is the last NuGet package that will build under SIL.BuildTasks 3.0. I will add the SIL.BuildTasks update to this PR before merging sillsdev/Mercurial4Chorus#33 so that CI will continue to build. |
New SIL.Chorus.Mercurial packages are built using a feature found in SIL.BuildTasks 3.3.0 or later, the ConsolidatedGuidFile parameter. This allows a single .guidsForInstaller.all.xml file at the root of a directory tree, rather than dozens of them scattered throughout the tree.
New Mercurial build has a very different file layout: instead of packing everything into a library.zip file, which turned out to be quite inefficient at starting hg.exe, the new Mercurial package has a bunch of individual files, which causes a much larger installer but is also much faster to start hg.exe.
These have also been removed from the fixutf8 extension in recent builds of the SIL.Chorus.Mercurial package, so GeneratedMercurialExtensions.wxs will fail if it still contains a reference to these files.
b7ce45e to
32fea00
Compare
SIL.BuildTasks 3.3.0 or later is now required in order to build correctly, so we should make sure that is mentioned in the changelog.
Since the WiX installer needs every individual file listed, and the new SIL.Chorus.Mercurial build is copying Mercurial source more directly instead of zipping it into a library.zip file, that means that future SIL.Chorus.Mercurial releases (e.g., 7.2.x eventually) are likely to cause installer failures until the WiX generation build tasks are re-run. So it's probably best to pin a specific version of SIL.Chorus.Mercurial here rather than saying `7.*`.
|
@jasonleenaylor The work on SIL.Chorus.Mercurial is completed; it is now 15 MB smaller and runs nearly twice as fast on Windows (at least the Chorus tests run twice as fast; actual speedup on a user machine has not yet been tested). I've tested the Chorus unit tests extensively, over and over, on Linux and Windows; everything still passes. Is there any other testing you'd like me to do before you take a look at it? |
rmunn
changed the title
I don't think so, I've started the installer testing |
2 participants
Version 7.0.1 of SIL.Chorus.Mercurial has been released, and tested to work on both Windows and Linux with no Chorus code changes needed (all unit tests pass). It's time to update the package version that Chorus depends on, so that downstream projects (like LexBox) that want to update to Mercurial 7.x can do so.
We specify
7.*instead of7.0.*because there is currently an open PR updating SIL.Chorus.Mercurial to version 7.2.2, and a7.*spec will allow downstream Chorus-using projects to smoothly update to version 7.2.2 of Mercurial later without requiring a new Chorus PR to be tested and approved.Important
There will soon be a new version of SIL.Chorus.Mercurial 7.0.1 that changes the build process in a way that would require SIL.BuildTasks version 3.3.0 or later. So I may need to also bump SIL.BuildTasks in this same PR in order for it to build. Not currently required until sillsdev/Mercurial4Chorus#33 is merged, but once sillsdev/Mercurial4Chorus#33 merges then SIL.BuildTasks 3.3.0 or later will become required in order to build the ChorusHub installer.
It would also be possible to say "version 6.5.1.43 or later", i.e.:
Or, to keep allowing all
6.5packages (6.5.1.18 was the first 6.5 package released):That would allow all future SIL.Chorus.Mercurial packages, including
8.xand later which don't exist yet. But it's entirely possible that Mercurial 8 will include breaking changes that would need a corresponding change to SIL.Chorus in order to compile, so it's probably safer to just accept7.*rather than a truly open-ended NuGet package range.This change is