staticSearch: new release, and release strategy
: Martin Holmes
Minutes: 70
We encountered an issue in Moses where we will need to pre-process the search string to account for some predicted input that does not match what we have indexed. This, in addition to the fact that I noticed that we weren’t doing Unicode normalization on the search string, meant that we needed a new release in the 1.4 line of staticSearch, but with the same fixes also being applied in the dev branch, which has already split decisively from the main branch where the releases were being done.
After checking with JT, I’ve created a new branch from the main branch, called release-1.4, and created a new release with the minor feature fix I needed. I made the same changes in the dev branch, and ran tests in both. Any projects currently subscribed to the main branch should probably be switched over to the release-1.4 branch from now on, with the confidence that only minor tweaks and bugfixes will be added there, with none of them backward-incompatible; being subscribed to the main branch will be risky in the long run because 2.0 will land there and break everything.
The instructions for making a release need to be updated, but we can do that as part of 2.0. I think from now on, what we should probably do for a major release is merge everything into main, then create a branch from main with the release number (release-2.0). Then any subsequent tweaks or fixes are applied either in dev and pulled into the release branch (if that’s practical), or made independently in dev and in the release branch if it’s not. We should probably not merge the release branch back into main because main should eventually get any fixes from dev anyway at the point of any major release.