Bump version in /lib/autokey/common on develop branch #912
Conversation
Note the change to the [/lib/autokey/common.py](https://github.com/autokey/autokey/blob/develop/lib/autokey/common.py) file on the **develop** branch.
|
Why am I not allowed to bump this version? Why is it giving me this assertion error?
A search for 0.96.0-beta.9 in the entire repository turns up only the I'm editing |
There was a problem hiding this comment.
There is no 0.96.x beta ATM and if there were, it would be beta.0 for the first one.
Maybe 0.96.1-develop.0 or something like that. Beta should be reserved for the beta branch. At this point, just 0.96.1 is probably the better choice until we have a defined new target release (no beta, etc. in the develop branch)
The beta.11 label was relevant when we were in the last prerelease of 0.96.0.
If this appears elsewhere, it needs to be changed, not conformed to.
However, this makes no difference until our release status changes. They should all be the same in develop, but only to make them easier to find and change later.
If we had a lot of people cloning develop and then filing issues or questions about it, then having an updated label of some sort to let us know where the code we're being asked about started might help, but we have very little activity of that sort.
|
It makes all the difference in the world: If you look at the
The beta and master versions are fine, but the develop version is incorrect:
Also, as a result of looking that file over on all the branches, you can see that the test that failed in this pull request obviously uses the version in the develop Since develop will automatically become beta once we feel it's ready, develop's version needs to currently be a beta for it to make sense. In looking at our release history, it seems to be our convention to start with a beta-1 instead of a beta-0, so that's what I'll do. I'll redo this pull request using v0.96.1-beta.1 as the version. The problem is going to be that the test will once again fail when I do that, because the test will use the current information in the /lib/autokey/common.py file, so heads up. You're about to get another failing PR, but I think it has to be put through that way so that all future tests will work properly and use the updated information. It may seem like I'm nitpicking, @josephj11, but this is important housekeeping work and all the little details do add up. I came across this issue while attempting to make sense of the mess that the |
|
OK. That clip was great! I'm not down in the weeds with you so I won't understand everything first try. (How many programmers does it take to change a light bulb? *) What I don't understand: What is the test that's failing and is it because the test needs to change? Develop doesn't "automatically" become the beta because not everything from develop will always go into the beta. I don't see how this can be accomplished without manual work. Logically, the release label of develop doesn't matter so if it needs to be beta something, it doesn't hurt anything. If making the release label of develop what you propose (beta 1 is fine. I wasn't sure about 0) breaks a test, what other problems does that create and how do they get resolved now or later?
|
|
That's one of my favorite videos of all time. You also got me with the light bulb question. The test that's failing is pytest (3.10) and the details of why it's failing are up above in this message. The develop branch does automatically become the beta branch. If you look at step 3 sections i and ii in the Our Git Flow workflow steps,you'll see that first you change to the beta branch with the The version on develop matters because we're human and we make mistakes (I'm really good at making those). If we forget to update it when we overwrite beta with develop, we want the beta version to go out for testing with the correct version number in it. This ensures that that won't happen. Aside from tests like the one that checks the validity of these pull requests, another problem would be that if a user greps for the version number in the source code, the wrong version would turn up, which could cause issues to be created by folks who notice that it's wrong or are confused by it being wrong. Last, but not least, it looks like the version is used in several places. Here's a grep for VERSION in a clone of the development branch that I just grabbed: debian/build.sh:VERSION=$(git describe --tags --abbrev=0 --match "v*.*.*")
debian/build.sh:DEBVERSION="${VERSION#?}"
debian/build.sh:dch --newversion "$DEBVERSION" ""
debian/build.sh:# dput "$PPA_Identifier" ../autokey_${VERSION}-1_source.changes
lib/autokey/gtkui/configwindow.py: dlg.set_version(common.VERSION)
lib/autokey/configmanager/configmanager.py: CLASS_VERSION = common.VERSION
lib/autokey/configmanager/configmanager.py: self.VERSION = self.__class__.CLASS_VERSION
lib/autokey/configmanager/configmanager.py: "version": self.VERSION,
lib/autokey/configmanager/configmanager.py: self.VERSION = data["version"]
lib/autokey/configmanager/configmanager.py: if self.VERSION < self.CLASS_VERSION:
lib/autokey/configmanager/version_upgrading.py:a different version (so NEVER set to common.VERSION), because this might skip additional conversion steps.
lib/autokey/configmanager/version_upgrading.py:setting config_data["version"] to common.VERSION ("0.97.0") inside the conversion function convert_v0_70_to_v0_80 will
lib/autokey/configmanager/version_upgrading.py: if not version < vparse(common.VERSION):
lib/autokey/configmanager/version_upgrading.py: if not version < vparse(common.VERSION):
lib/autokey/configmanager/version_upgrading.py: configuration_manager.VERSION = common.VERSION
lib/autokey/qtui/dialogs/about_autokey_dialog.py: self.autokey_version_label.setText(autokey.common.VERSION)
lib/autokey/autokey_app.py: version=common.VERSION,
lib/autokey/argument_parser.py: version="%(prog)s Version {}".format(autokey.common.VERSION)
lib/autokey/common.py:VERSION = "0.96.0-beta.9"
lib/autokey/common.py: version=VERSION,
setup.py: version=search_for("VERSION"),
setup.py: # If using this, would have to also set common.VERSION from this so that
tests/test_common.py: assert_that(git_tag_version, is_(equal_to("v"+autokey.common.VERSION)), |
|
If you've ever worked on a project that involved hardware and software (let alone firmware), the light bulb question is even better because there can be lots of finger pointing between those two aspects of such a project. OK. If beta is effectively a copy of develop, the beta label makes sense (once it's restarted at 1 for the next release). Then, I guess we have to do some sort of reverse cherry picking to remove anything copied from develop that isn't ready to be in the beta/next release or we have to keep everything like that from getting into develop in the first place. As a thought experiment, I would consider adding Sam's new uinput (or whatever it's called) stuff to develop, but that couldn't be included in a maintenance release. Any ideas on the best ways to do that? Once we make beta 0.xx.1, do we update it directly with bug fixes, etc. or do we do those in develop and rebuild the beta again for 0.xx.2? The latter sounds cleaner, but it's more work. |
|
I think cherry-picking will only be useful when choosing what to bring onto the develop branch from feature branches. If you release a beta and people like it, all of it should go onto master and master should then become the new AutoKey version. At least that's my understanding. Sam's new code will add itself in when you merge his PR. A beta release is unchangeable. Once it's out, it's out. If it needs work, it doesn't get worked on. We go back to the drawing board on develop and lather, rinse, repeat our way through the steps to create a new beta release from develop in its current state, and so on. We can repeat that as many times as needed until we're satisfied. Your questions have been very helpful in fine-tuning the workflow information. I've updated the detailed steps in this message and have whittled my understanding of it down even more here so that it can be reviewed and improved upon:
|
|
That clarifies a lot. It sounds like it's almost exactly what I wanted in the first place, but adapted to how Git and GitHub actually work. IIUC, once you merge a feature/bug branch into develop, the feature branch is dead. You don't update it if you change anything in develop. You create a new feature branch if you need to do something else. This brings up the issue of dealing with several feature branches at once because presumably you and other developers may be working on more than one thing at a time. I assume that the order of merging these into develop might make a big difference if they overlap at all - with whomever goes first having the least amount of work to do. This will probably be resolved on a case by case basis, but it's worth thinking about. We'd want to figure out the optimal/easiest way to do it if there were any significant differences. It probably shouldn't be just first come first serve. It should be coordinated. I don't understand the hard reset part in 9 c and d. It sounds like good work is being discarded, but I doubt that's the case. Sam is a maintainer, so he can merge his own code when appropriate. IDK if he wants to merge it yet. Another level where coordination is important. |
|
About the feature branches: For the feature branches (or any branch, actually), when you delete them from within GitHub's pull request invitation, they don't seem to actually be deleted. They just vanish from the GitHub branch listing (and go into some sort of inactive purgatory). If you create them again, they seem to be revived in the same condition they were in when they were "deleted" by GitHub. If, however, instead of deleting a feature branch from within a pull request, you delete it in git or with the little trash can in the branch listing on GitHub, then it's totally gone and can be created fresh the next time. Thanks for asking about that. No wonder I've made such a mess. This is why I've disliked feature branches. I guess I'll be using the trash can or git to get rid of feature branches from now on so that I can learn to love them. About taking turns with other developers: I have no idea how this is handled in other projects and I don't know if we have a policy on that. Basically, even if you had a policy, there would be occasional mess-ups (I'm good at those, so I'm certain I would contribute to that pile). That means there will be conflicts and they'll need to get sorted out. Sometimes that involves manual edits of files that are in conflict and other times it involves discussion with other developers to figure out the best way forward. Git makes it possible to undo and edit commits (I'm just now starting to learn that sort of thing), and edits are offered as part of the conflict process and can immediately be done. About the hard resets: The hard resets in 9 c and d are done because the goal is to get you as close as possible to the same condition you were in after performing steps 1 through 3. In other words, we no longer need to create a brand new master (as in step 1) because it already exists and we no longer need to create a brand new beta and a brand new develop off of the master (as in steps 2 and 3) because they already exist. The closest we can come to that is to make them all as identical as possible and put them all at the "starting gate" with no staged or unstaged files and no commits that are ahead of or behind one another so that we have a clean starting point for the next version's development. We don't care about the condition that beta is in because its only job is to become an identical copy of develop and be immediately released upon the world for testing. It's overwritten each time that happens, so it can be in any condition at all without having any effect on anything. We can just ignore it most of the time. In looking at the steps above, 9 e should come before the hard resets in 9 c and d, because we don't want the commit that changes the develop version to put develop ahead of master. I'll fix that. <-- So, when you're looking at this and looking at 9 c and d and e, the hard resets that you had mentioned will now be in 9 d and e. Sorry about that, but your feedback is showing me my mistakes and if they don't get fixed right away, they might just stay that way accidentally. |
Add this to your GitHub hints page when you get a chance. It's not obvious, so it may help other developers,
What I'm saying is that when a substantial PR or set of PRs is done maybe the author should post somewhere (maybe an issue here) with something like: I have an update of these files (list with PR #s) ready to merge. Then if anyone else is working on those they should contact you promptly (on Gitter?) to coordinate the merge(s). If you don't hear anything after a few days, then the merge can proceed. If this was done on a "meta" issue opened just for this, then all the interested parties could follow it (or comment on it) so they get notified when anyone posts on it. It would not be used for discussions, etc., just for ready to merge notices or anything similar that might affect other work. It could be called project management notices. This would also be a good place to announce when a release will soon be frozen so developers know they have until some cutoff date to submit PRs for it. Alternatively, we could start another channel/room on Gitter just for this. Whatever we think will work best. AutoKey has always been a one developer (with occasional other contributors) project, so there are no policies or provisions for project management. This is us starting to change that.
How do you know when it's safe to do a hard reset? I'm not clear on where these "staged or unstaged files" come from and where any incomplete work would be saved so it's not lost in the reset. I think what I need to see is a similar workflow for what occurs before this one so I can see where things come from and where they go. (I'm not saying you need to create that.)
Good.
That's as it should be. I'm a bit better than a rubber duck. :) |
It was my mistake. I'm still learning a lot of this. They get created in the same state as their current parent branch. It's a git behavior rather than a GitHub behavior.
Although communication is never a bad idea, I wouldn't make it a rule. The more things people must do, the fewer the number of people we'll find who are willing to do them. I think we do that anyway when contemplating anything of significance. Also, I'm currently far too small of a fish to be of any consequence to anyone who's working on major changes to AutoKey. I believe Sam is our only real developer, so however he'd like to do things is fine by me. I also wouldn't use Gitter. There are ways to communicate right here where the development happens, so it's best to keep as much of it "in house" as possible.
We've got the Maintenance goals category in the AutoKey Discussions section on GitHub that would work for something like that.
Sure.
I think it's a bit soon for us to make any of these kinds of changes, because we're not experiencing growth that's straining our current approach beyond its limits. Also, when it comes to all of these situations in which more than one person could be working on the same thing at once, this is exactly what version-control systems, like git, are designed for. They make it so anyone can work on anything without worrying about what anyone else is working on, because it will all be sorted out nicely in the end. I think the main concern would be wasted man-hours if you had more than one person working on the same thing. There's always the possibility that each will have a very different approach, though, which means they could each learn from one another and could perhaps come together in the end for yet a third approach that's a hybrid of the two, which would never have happened if only one of them had been working on it. What's that saying about eggs? Six of one, half a dozen of the other...
In the case of the beta, it's safe to do it at any time, because we don't care about the beta. We're doing it right before it gets overwritten with the contents of develop, so it just makes sure it's synchronized with the master branch. I'm not a hundred percent certain about whether we should be doing hard resets on master and develop as part of our steps and would welcome any input I can get. Meanwhile, I'm slowly doing tests on a local level to familiarize myself with how all of this stuff works and what each command does or doesn't do (it's amazing how wrong some of the information I've found online is). I'm also doing research to see how other prepare their repositories for the next version once they've put out a release. This research is messy since there are a million opinions and I'm stuck figuring out which of them ought to be followed, which is a slow process of elimination based on tests, tests, and more tests.
When you add files or directories to the repository or when you change or delete files or directories in the repository, git notices that you did that and has these three ways of understanding what you've done: unstaged, staged, and committed. TLDR: Unstaged = Are you sure? Staged = I'm sure. Committed = Let's do it. NOT TLDR:
Note that the only stage that has any impact on the project is the one in which you make a commit. The other two stages are a little necessary conversation between git and you where you nod back and forth with one another and keep tabs on the current condition of the stuff you're working on that git can't help but be interested in. It may seem unnecessary to have an extra step between creating a change and committing it, but it's a way to keep your stuff organized and give you more than one opportunity to back out. You may have changes that you're completely unsure of or not finished with that should stay unstaged until or unless you become sure of or finish them. You may have changes that you're sure of or finished with, but not ready to commit yet (perhaps you're doing a bundle of related changes all in one commit). Staging them makes it immediately obvious to you (and to git) which ones are ready and which ones still need to be done. And finally, committing them clears the decks, leaving only any unstaged changes if there are any. Last, but not least, both unstaged and staged work is lost with the kind of reset that we do (the two branches will have an identical history and identical files). There's such a thing as a soft reset that preserves them, but that's not necessary in our case.
It's what you're currently seeing. All of these little commits and merges that we're doing are leading up to this. When enough of that has gone on that one or more of us thinks what we've got is worthy of a new release, then we go on to these steps. I'm trying to iron them out so that we'll know exactly what needs to be done when the time comes and not leave anything out.
Definitely. The disadvantage of a rubber duck is that it can never be truly interactive, unlike you, so your contributions to the conversation are always welcome and tend to cause leaps that may not have happened otherwise. Speaking of which, all of these questions have gotten me to look more deeply at all of this, and my understanding of how the hard reset works was incorrect. It seems that the way that we're using it, it removes all staged and unstaged changes from beta, resolves conflicts in favor of the master, and updates the beta branch's tip (its most recent commit) to the commit at the tip of the master branch, which makes it so that the two branches are identical, are nestled together like mother and child, and comparisons between them, as they each go their separate ways, will be done from that point forward. |
|
Tldr Explaination of this failing test: it checks if the most recent git tag in this branch matches the version info in common.py. The risk it controls for is creating a release with git tags and forgetting to update common, which would lead to users seeing the wrong version string in their autokey about section. It is a frustrating test at times, so if you want to accept the above risk you can delete/disable it in the relevant test py file. |
@BlueDrink9 Is there a way to make such a thing a "warning" instead of an "error" so it produces a notice, but still lets the tests pass? Would that be a good idea? |
|
@Elliria I don't believe I have seen any staged or unstaged changes to actual AutoKey branches. I can understand why they might be useful in a personal or feature branch, but I don't see how they apply to develop or main. This is not a judgement/opinion statement - I just don't see the use case(s). Maybe such changes would be appropriate if I just wanted to inject some code to try something out or debug something - changes that I would want to be able to easily remove once their purpose was fulfilled and that were never intended to be incorporated into a release. |
This is a bit confusing. My understanding is that a particular beta release is static - with no modifications - so there shouldn't be any flotsam and jetsam to get rid of. Also, we are going from develop to beta, not master to beta, so resolutions back to master might be a problem. What are we doing that make hard resets have anything at all to do? Maybe I'm missing something. |
Not possible, also not helpful (at least for releases - harder to undo a release with the wrong version than a tag with wrong version). Should be able to make it only run on master, maybe? |
Bump the version in the /lib/autokey/common.py file on the develop branch to 0.96.0-beta.11.