Updating workflows on numerous branches

[Elliria]

Choosing the version range

This discussion was opened in response to a comment by @josephj11 in which he noticed that Python 3.7 has reached end-of life and should be removed from the workflow tests.

We're going to need a range of Python versions to satisfy some of the files in the /.github/workflows/ directory.

If you look at GitHub's available images, the ubuntu-dd.04 image is the latest one being used by GitHub. If you do a search for python on that page and go to the third result. you'll see the range of versions supported for that image. Those are:

• 3.7.17
• 3.8.17
• 3.9.17
• 3.10.12
• 3.11.4

If you then visit python.org's Status of Python Versions page, you can see which versions are currently supported. Those are:

• 3.8
• 3.9
• 3.10
• 3.11
• 3.12
• 3.13

Version 3.8 (or 3.8.17 when that's needed to be specified) is still getting security updates until October of 2024, so we could make that the lowest version in our range.

Version 3.11 (or 3.11.4 when that's needed to be specified) is the highest version the current Ubuntu image support, so we could make that the highest version.

Lots of people (myself included at times) hang onto the security versions and only update when they no longer have any alternatives, so by choosing the lowest-possible version, we'd be including more users, but I'm not sure what our view is on that. What do you think?

---

Help wanted with advice on the best git practice for updating the workflow files

When doing these version updates, we'll be creating another another of our messy multiple commits, because none of the changelogs are the same on the various branches, yet they all have the same name, so this will create more aheads and behinds in our git history.

It distresses me to keep making our branch mess worse and I know the team would like it if we could do this as cleanly as possible. Does anyone have a suggestion for making such a change cleanly?

For those who are willing to read along, I've created this description of the dilemma:

We have three main branches: beta, develop, and master. Both beta and develop are based off of master, but all three branches have gone in different directions and are unique in many ways.

There are some files that exist on all three branches. Sometimes we want the contents of those to remain identical when we make updates, but in other cases, the contents need to remain different.

When changes are made to beta and develop, those branches are then considered to be ahead of master, which is fine and as it should be.

When, however, a change is made to master, then beta and develop are considered behind and need to be updated.

In a case where the file on master must remain different from the same file on beta and develop, the aheadness and/or behindness of the branches has to be left unresolved.

In an effort to make as little disruption as possible and cause the fewest possible aheads and behinds when trying to update a file that should be identical on beta and develop, what would my best technique be?

I've seen references to cherry-picking, merging, and rebasing, but have yet to make sense of it all.

[josephj11]

TL;DR: This is mostly a mole hill. We can probably support any range centered around the current version in Debian without any noticable consequences as long as we don't go too far in either direction.

WRT updating our various branches, we definitely need assistance with establishing procedures that don't create as many problems as they solve. This is a generic problem that must already have good solutions. We just have to find them.

IIUC, these tests are only applied when we attempt to merge new PRs, so they would have no direct effect on the viability of older saved versions of our code.

Indirectly, if we introduce a change which is incompatibe with e.g. Python 3.6, that would make our develop branch and, eventually, our master branch, fail in some way on a system that is stuck at 3.6 - and - we wouldn't be alerted to this when merging the change.

First, older systems usually expect to run older versions of applications for precisely this reason, so that's not a major concern. We just need to note changes to what our minimum versions are (of whatever comes up) in the changelog for each release. (I wouldn't go looking for these, just note them when they are brought to our attention.)

Since we maintain a lot of older versions on GitiHub, this makes it easy for an affected user to remedy this situation.

This brings up a related very minor concern. When should some of these older versions be removed from GitHub?

Since our code base is tiny compared to a lot of other projects, space isn't a issue. It's just about useless old clutter. And, maybe, the implication that if we still host a very old version, we would still support it.

Maybe we should add a note somewhere stating the range of versions which are supported. If someone asks about 0.90.4, I don't want to spend any time on that. Where to draw the line on newer versions isn't that obvious. I don't really want to support anything lower than 0.96, but since 0.95.10 is probably still widely installed, supporting that makes sense as well.

On the other end, we probably don't care about twinkles in the developers eyes for Python 3.20, but it would be nice to know if we are introducing a change that will bite us in the less distant future. The question here is how far ahead do we want to look - because a failed test for e.g. Python 3.12 would block a merge now for a version of Python we may not have to actively deal with for a couple of years.

If there is a way to make a failure in a distant version a non-blocking warning rather than a blocking error, that could allow us to look farther ahead without penalty. I'm not sure when these newest specs are frozen, so if we look ahead far enough, we could run into problems that might go away or change as the specs are revised.

Since no projects/packages I'm aware of depend on AutoKey, there don't seem to be any pressing obligations for us to set a particular range of Python versions we support other than keeping our users happy and making sure we're not needlessly creating issues for our developers in the short- or mid-term.

So, we have to support the current versions on Debian and Arch (Arch is usually newer). Anything beyond that depends on what it costs us to support. We shouldn't reject a PR because it won't work in 3.6 or 3.12. Other than that, we really don't know much about our actual user base so the choice of version range is somewhat arbitrary.

Another concern: What if someone submits a PR which uses a new feature that only works in 3.11? Presumably, some or all of the older version tests would fail. What do we do then?

[Elliria]

Then for the Python version range, I guess we should go with the lowest level supported by Python and for the highest level supported by the GitHub image. Does that sound good?

The workflow tests are being run from the master drive and are controlled by the python-test.yml. It just so happens that the contents of the python-test.yml file on all three branches are identical other than the white-space (which will be easy to fix and should be made identical anyway).

It occurs to me (and this may solve our synchronization issues if we do it everywhere from now on) that in an ideal world, the develop and beta branches would always be ahead of the master branch, so we should strive to make that true as much as possible.

To that end, if I were to edit a file that exists on all branches on the master branch first, then the other two branches would display a notification that they're behind. GitHub would then extend an offer to synchronize the data at the push of a button (which I do all the time with my fork in response to the notification whenever you put a PR through). If I'm guessing correctly, that will mean that the other two files by the same name on the other two branches will be updated automatically by doing that and won't need to be updated separately. Not only that, but there should be no annoying notifications afterwards, either.

We can test this theory with the python-test.yml file if you like, @josephj11, since it needs to be updated anyway.

[josephj11]

I'm with you on most of this with one significant difference.

My idea of how things should work is a strict hierarchy of master<-beta<-develop.

Develop can contain anything generally accepted as a good idea that works well enough for others to test.

Beta is a subset of develop that contains those changes from develop that we intend to include in the next release.

Main is the current release with a few small, non-critical updates for things like keeping the actions working or updating documentation.

When we are ready to issue a new release, Master should be replaced by beta - making sure any updates made directly on master are preserved.

As much as is possible, any changes made to beta should also be made in develop. This won't always be possible because develop can contain breaking changes that are not ready for release.

When we are ready to start a new release process, beta should be replaaced by a subset of develop (not including things that are not ready for release). E.g, develop could contain a new feature for 0.97 and that wouldn't go into a beta for 0.96.1.

If there's a better way to separate things in separate develop branches, etc. that's fine. I want it to work conceptually as above even if the details on how to do it are different.

How to get all of this to work using GitHub and Git commands is beyond my understanding.

[Elliria]

If you did that, you would introduce grandparents and grandchildren into the mix, which would be additional messy layers, because:

• every grandparent is a parent
• every parent is a child and a parent
• every child is a child

Since all parties are either a parent or a child or both, everyone is always interested in everyone else and always gets a notification about being out of whack every time anyone changes anything. If they then choose to also get the change, all is well. If they don't, they stay messy. This just keeps happening and the whole thing gets more and more untidy as time goes by.

We're having a related, but not identical problem in that our siblings, who have no interest in each other, are all kinds of interested in Mom, who's also all kinds of interested in them. They and Mom have had changes since they were born, and each of them are in varying and different states of untidiness in comparison with each other since not all of them have opted for what the others have changed and two of them don't even know that they could if only given the chance.

I seriously think that git branches would make great material for stand-up comedy.

[josephj11]

So, what you are saying is that the tools won't support what I want to do and it would make things worse. OK. I give up!

This reminds me of a TNG episode where Data is trying to learn to be a standup comic. He finds that the funiest comedian was an advanced mathemetician and skips him because no one would understand the jokes. :)

[Elliria]

No, no - not at all. They'll support pretty much any setup you'd like to use. It's just that some setups case more trip-wires for us to fall over than others. As a real-life comparison, instead of grandmother, mother, and child, we currently have mother and children. Despite mother and children being the gentler of the two setups, you can see the mess that it invites us to create.

[josephj11]

There's a big difference between a tool letting you do something and a tool supporting you in doing it. All these conflicts mean either we're not using the tools optimally or the tool designs/implementations are lacking. It could be either or both in this case.

[Elliria]

This brings up a related very minor concern. When should some of these older versions be removed from GitHub?

Whenever we notice them. I'm not sure how often versions get updated on GitHub and Python, so it's just a good idea for all of us to occasionally look.

[Elliria]

I think I have it working and I made Discussion #888 to call for testers, but only you and I participated and nobody tested. You suggested putting the call for testers onto Gitter, so I did that. Last I checked, nobody had responded. I'll check now. No response. I'll keep testing.

[josephj11]

If the testing requirements aren't too tricky, you can post on Google where there are more users.

[Elliria]

I don't know if they are or not. I've tried to make them clear, but the whole point of the testing is to get feedback on the steps and whether they work, so if they're tricky and need simplifying, that would be useful feedback. How do they seem to you? Is it worth a try to post them on Google?

[josephj11]

Those instructions are very clear, but they are complicated. I would just preface the request with something like "This isn't for Linux newbies. You should have a basic familiarity with working from the CLI".

[Elliria]

Done. Thanks for the feedback and suggestion. I made it the first bullet-point on the page.

[Elliria]

Maybe we should add a note somewhere stating the range of versions which are supported. If someone asks about 0.90.4, I don't want to spend any time on that. Where to draw the line on newer versions isn't that obvious. I don't really want to support anything lower than 0.96, but since 0.95.10 is probably still widely installed, supporting that makes sense as well.

I'm not sure. We've never drawn a line in the sand on this. If it's working for us, maybe the "if it ain't broke, don't fix it" slogan would serve us well here.

[josephj11]

You're probably right.

On a complelely unrelated note, I just looked up "made from scratch" and it originated with people scratching a starting line (like a line drawn in the sand) for a race with possibe handicaps given to some by having them start in front of it or behind or before or after the others.

[Elliria]

On the other end, we probably don't care about twinkles in the developers eyes for Python 3.20, but it would be nice to know if we are introducing a change that will bite us in the less distant future. The question here is how far ahead do we want to look - because a failed test for e.g. Python 3.12 would block a merge now for a version of Python we may not have to actively deal with for a couple of years.

I suspect that the future is too complex and unpredictable to adequately plan for, so it's probably best to do the very best possible job today in the hopes that that shores us up against whatever's coming.

If there is a way to make a failure in a distant version a non-blocking warning rather than a blocking error, that could allow us to look farther ahead without penalty. I'm not sure when these newest specs are frozen, so if we look ahead far enough, we could run into problems that might go away or change as the specs are revised.

I'm not sure on the timeline for new versions, either. As for the non-blocking vs blocking errors, version-specific changes often are significant enough that only a blocking error would do, but I suppose it's something that could be taken on a case-by-case basis.

[josephj11]

As for the non-blocking vs blocking errors, version-specific changes often are significant enough that only a blocking error would do, but I suppose it's something that could be taken on a case-by-case basis.

It's mostly a moot point because we don't develop actions and they're not generally available for distant future releases.

However, my point is that while I'd like to know if a change made now will break in 3.12, I woudn't automatically reject such a change because it won't matter for some period of time. They're just previewing 3.12 features now. I don't think it's even available for general users yet.

[Elliria]

We develop scripts that use actions and those are version-specific.

I'm pretty sure that the kinds of changes that would cause scripts to break are usually significant, like when Python comes out with a new version. They usually give us lots of advance warning, so that we can figure out how to convert our stuff over before the time comes.

[Elliria]

Another concern: What if someone submits a PR which uses a new feature that only works in 3.11? Presumably, some or all of the older version tests would fail. What do we do then?

I've never heard of such a thing, but even if it did exist, it would be something we would want to try to avoid or find a work-around or alternative for. The only other way I could see such a thing being addressed would be for us to put out a specific version of AutoKey as a specialty release with only that version of Python in it so that that particular feature could be enjoyed or used. That does seem a bit extreme and far-fetched to me, though, and not like something we'd want to do.

[josephj11]

I think you're right. If someone submits a PR using a feature only available in 3.11, we'd either have to reject it or hold it indefinitely until 3.11 was the lowest supported version.

So all PRs have to work on the lowest version we support. This provides motivation to remove older version support when it makes sense so that features from newer releases can be used.

[Elliria]

Well, I've attempted to get information that would be helpful for updating our workflows. Interestingly, despite numerous attempts (at varying times of day and night) to get live help on IRC, I seem to have the power of invisibility in the GitHub channel. That leaves the rest of the internet as the main resource, so I've attempted to decipher the discrepancies in what can be found in a million locations and distill it down to what, hopefully, is the actual truth. I'm not sure whether I've succeeded, but this is what I've got so far:

• git cherry-pick copies a specific commit from the source branch and adds it to the target (current) branch as a new commit with a new commit hash.
• git merge combines the changes in the form of commits from the source and target (current) branches and adds them to the target (current) branch as a single new commit with a new commit hash.
• git rebase moves changes in the form of commits from the source branch to the target (current) branch's HEAD as new commits with new commit hashes.

What that tells me is that we will always have new commits and new commit hashes no matter how we do things.

Do you think I should cherry-pick when making identical changes on any two or more branches? This is the current plan:

• My approach for identical changes to the same file on different branches would be to favor master over develop and beta. Whenever master is one of the branches involved in an identical change, I would make the change to master first and then cherry-pick it onto the other branch or branches.
• My approach for non-identical changes to the same file would remain as they've been with separate commits being made to each branch.

Hopefully those will work fine. If not, please jump in with suggestions.