Release issues

[samiebee43]

I've updated our github releases page to have most of the new versions, but there remains a couple of release-related issues:

• [x] 1. There is an erroneous tag enlighten-4.0.22 in addition to 4.0.22 and they are one commit apart

Normally the enlighten-x.y.z tag should appear in the Wasatch.PY repo. (There is already one there too)

• [x] 2. We don't have changelogs for 4.0.22rc and 4.0.23rc on main. (The way I will correct this is by copying the contents from 4.1.0-dev CHANGELOG.md into the github releases page. In my mind the Github Release page is the official changelog).

• [x] 3. There is no enlighten-4.0.21 tag on Wasatch.PY

• [x] 4. ~There is no installer for 4.0.21~ (wontfix)

• [x] 5. A series of 4.1.0 changes are listed in CHANGELOG.md under 4.0.25. Actually that version will only have persist save location. Addressed by #341

• [ ] 6. There is no 4.0.24 tag, but there's an installer.

• [ ] 7. There is no enlighten-4.0.23 tag on Wasatch.PY. Based on the dates, I would guess it should be applied to 86afac9d0

• [ ] 8. There is no enlighten-4.0.24 tag on Wasatch.PY

[samiebee43]

I believe the best way to address (1) is to remove enlighten-4.0.22 tag and move 4.0.22 tag to 09e167b. It's a change in a dependency file, which seems important for the release.

(Done.)

[samiebee43]

@mzieg I'm pretty sure you can fix (6) with git push --tag. Since the tag must exist somewhere for the installer to be built.

[mzieg]

the tag must exist somewhere for the installer to be built

Actually no. The tag must exist for the installer to be deployed...which it wasn't (deliberately).

[mzieg]

I've updated our github releases page to have most of the new versions

I'm not sure any of those were actually release candidates. 4.1.0 was expected to be the next release, and it was known that there were many features which would have to be added before that was ready. We were never going to release most of these incremental steps...that's why they were never merged to main, or even had a pull request to do so.

[samiebee43]

I think we need a more formal build process.

I was under the impression that (1) all builds should appear in Github Releases (2) all builds increment at least the minor version number (3) almost all builds should come from a commit on main (with the exception of downstream patches like py37-ubu).

I will draft a Github Wiki page consisting of what I think the rules should be when it comes to building and releasing. It will be similar to the Beta-release page from our internal wiki, but it won't contain instructions for deploying to our website. It will contain some updates regarding RC vs beta and the use of staging semi-major branches. The document is open for collaboration, and can be found here: https://github.com/WasatchPhotonics/ENLIGHTEN/wiki/Build-and-Release-protocol

[mzieg]

almost all builds should come from a commit on main (with the exception of downstream patches like py37-ubu).

Then what's the point of a dev branch like 4.1.0-dev?

To me, the point of a dev branch is so we can make many "internal, test" builds, which aren't from main, and which most customers would never see or be aware of (since they're presumably tracking the "stable" main).

[samiebee43]

My purpose for the dev branch is that we can work on an arbitrary amount of changes for a new semi-major version--and while we work on it, if we receive a support request (such as making the data save directory persistent) then we can roll out a 4.0.25 from main without including all the arbitrary amount of changes we are queuing up for 4.1.0.

When 4.1.0-dev reaches maturity it will be merged into main, and all subsequent releases will be 4.1.x.

[mzieg]

an arbitrary amount of changes for a new semi-major version

But why would those be automatically considered release candidates? Who intended, or wanted, to release them? I didn't.

[samiebee43]

Those arbitrary changes aren't release candidates, they are rolled into the 4.1.0-dev staging branch. I'm referring to this branch structure, where lots of bigger changes go into staging to be released in the future, but small changes can be made to the last release for customer support.

This is exactly the scenario we have now with many future features in 4.1.0-dev including themes, jcamp write, refactoring, etc. But for customer support I only wish to release one small change on top of the last release.

The 4.1.0-dev should be merged to main in the future when it is ready.

[mzieg]

These were internal test builds