Fix release process: use *.999 for development versions

[artoonie]

Use 1.3.999 for package version, and mark it as such in the UI.

With *.999:

Without:

[HEdingfield]

Extremely reluctant to do this. I don't want packages running around in the wild that have version mislabeled like this, especially if you're planning to make a public pre-release tag.

What's the downside of not making this change? jpackage won't work? If so, how did we test this on GitHub before?

I'm probably fine with jpackage failing until we do a real release, because I think jlinkzip will still work, which should be good enough for testing purposes.

[artoonie]

I was reluctant too, but I think it's worth the tradeoff.

1. If you look at the filenames, they won't have this version number; they'll instead have whatever tag we use.
2. When you launch RCTab, it will show the internal version number, which includes -alpha.
3. This was a known issue in the last PR. We used 1.3.1 for testing throughout the lifetime of that PR, then updated to 1.4.0-alpha at the very end. See this final commit and this discussion.

All this means that there will be a version labeled 1.4.0 in the metadata, but it won't be visible anywhere outside of the metadata.

Alternatives:

1. We autoincrement the patch number more frequently, and become okay with releases like 1.4.106.
2. We allow jpackage to fail, and only upload jlinkzip if that's all that succeeds. (Downside: you must have java installed to test a development package.)
3. We use a patch version that's static and means in development, that's older than the next planned release, like 1.3.999.

Since in the future, most users will be testing the software without java (i.e. using the installer instead of jlinkzip), I'd urge against (2) since that would mean that RCVRC is testing a slightly different workflow than election operators.

[HEdingfield]

Points you raised:

• 1 = good; little confused about what these lines of the script actually do then... just temporary intermediary file names that are then replaced by the branch-based ones?
• 2 = good; and I assume the logs and config files will show this too, which is good.
• 3 = understood.

So the only place this will be surfaced is, e.g., in the system registry where it indicates which version it is, and potentially in the installer?

Of the alternatives you presented (thanks for these), I like 3 the best, but it's still kind of janky. Is there suddenly a big push to make testing dev versions a public and widespread thing? I spose I could live with alternative 3 if that's the case.

@tarheel @chughes297 feel free to chime in too.

[artoonie]

I'm always of the opinion that "it should be trivial to deliver a release-quality build to non-developers at any time," but recognize the need may not be universal. Don't think we should make code tradeoffs we're uncomfortable for it.

1. Yes, these are just intermediary file names

Yes, it shows up in system registry, installer, Right Click > Properties, etc:

One potential issue is whether an installer would prevent you from installing because it think you have the same version already -- I haven't encountered that, but I suppose it's possible for an installer to say "Hey, you have 1.4.0 already, I refuse to install the new one."

[HEdingfield]

Ok, I think I could live with this as-is. I might still probably feel just a tiny bit better going the 1.3.999 route, but not really sure. @tarheel and @artoonie what do you both think? What's the downside of doing 1.3.999 over keeping it as-is?

[artoonie]

1. Done
2. https://github.com/BrightSpots/rcv/wiki
3. Done (see screenshots above)
4. Done

[HEdingfield]

This all looks great! However, one other thing popped into my head since we're currently working on both 1.4.0 and 1.3.2... how does this convention work if we're doing a minor update, like 1.3.2? Can we do 1.3.1.999, or will that break things?

Similarly, what if we're doing a major release like 1.4.0 to 2.0.0? Do we make it 1.999.0 for dev, or 1.4.999, or what?

We should sort this out and update the Wiki accordingly.

[artoonie]

I'm okay with any convention. It seems to me that 1.3.999 should be the version number for all 1.3.x, meaning both 1.3.0 and 1.3.1 will have the same development version.

[HEdingfield]

I personally prefer 1.3.1.999 for the pre-1.3.2 version, and 1.999.0 for the pre-2.0.0 version.

We can easily accommodate the latter by checking if "999" is anywhere in the version string, but will the former still work with jpackage (or whatever the original motivator was for this whole PR)?

[HEdingfield]

In Slack, @artoonie confirmed that a version like 1.3.1.999 will break things for the Apple (a hex upon them) build.

I reluctantly agree, then, that we can use 1.3.999 for a development version of both 1.3.2 and 1.4.0 (and 2.0.0, for that matter, if we were going straight there from 1.3.1). I'll outline this more in the Wiki here.

[HEdingfield]

Per our chat today, let's finalize this PR by:

1. Going the route of making this version 1.3.999 (and setting it up so future alpha releases will follow the same .999 pattern)
2. Figuring out exactly where we should note this development convention (e.g. in the Wiki somewhere?)
3. Adding a little warning banner in the GUI and/or in the logs when booting up that detects a version x.x.999 and warns the user that it's an alpha version, not to distribute it, etc.
4. Changing the name of the PR accordingly

[artoonie]

(FYI, this is ready for review)

[tarheel]

Seems fine but will let @HEdingfield approve.

[HEdingfield]

This all looks great! However, one other thing popped into my head since we're currently working on both 1.4.0 and 1.3.2... how does this convention work if we're doing a minor update, like 1.3.2? Can we do 1.3.1.999, or will that break things?

Similarly, what if we're doing a major release like 1.4.0 to 2.0.0? Do we make it 1.999.0 for dev, or 1.4.999, or what?

We should sort this out and update the Wiki accordingly.

[HEdingfield]

In Slack, @artoonie confirmed that a version like 1.3.1.999 will break things for the Apple (a hex upon them) build.

I reluctantly agree, then, that we can use 1.3.999 for a development version of both 1.3.2 and 1.4.0 (and 2.0.0, for that matter, if we were going straight there from 1.3.1). I'll outline this more in the Wiki here.