Release Schedule

[jisaacks]

@r-stein @rchl

Hey guys, I have been really appreciating the all the hard work you have been doing. In light of all the recent activity. I wanted to discuss on a plan for managing everything.

What do you think of always having an open issue for the next release, where we can keep track of what is going to be included in the next release, the changelog etc. It would be a central communication hub for everyone to communicate on progress for next releease. Then once everyone approves the release. I can cut it. I would then be fine with y'all merging PRs as you see fit, as long as we are adding to the changelog and all in communication.

This plan may suck, so let me know what y'all think or any modifications to this plan, of if you just think it's bad idea, etc. Let me know! Thanks.

[r-stein]

Using milestones seems to be a good idea to group PRs and issues for releases. Additionally creating an issue per release isn't bad either.

[rchl]

I'm all up for trying it.

[jisaacks]

Do y'all have merge rights?

Let's try this, if one of you approves, the other feel free to merge (prefer rebase.) That way you are always both signing off. Let's try that and see how that works.

And lets try to add milestones, and an issue tracking each release if we can. I'll still cut the releases.

[rchl]

I think I do. At least I see the merge button.

As for "prefer rebase". I hate including fixup! commits or commits that just fix issues in the pull request in the final history. So would prefer squashing all commits (or at least do it when it makes sense).

#331 is one example where I would prefer squashing as it has some commits that fix earlier problem of the pull request or just adds changes that are later removed.

But I guess common sense should be applied on a case basis...

[jisaacks]

So would prefer squashing all commits (or at least do it when it makes sense).

My only reasoning against squashing, is I like to give contributors, higher numbers in the commit graph if they did a lot of work. If someone wrote 50 commits, and we squash it to 1 commit, it puts them low on the commit graph, when in fact they helped out more than what the graph portrays.

#331 is one example where I would prefer squashing as it has some commits that fix earlier problem of the pull request or just adds changes that are later removed.

If it makes sense to squash it or merge, I am fine. I just prefer rebasing if possible because it usually makes the tree a little cleaner. But isn't always worth it.

Just use your own judgement/discretion.

But I guess common sense should be applied on a case basis...

Exactly! :)

[jisaacks]

Oh one last caveat, if someone wants to make a change that fundamentally changes gitgutter, or is controversial, etc. I'd like to be included in the decision before merging. Otherwise for bug fixes, small features, etc. Feel free as long as any other member approves first.

[rchl]

My only reasoning against squashing, is I like to give contributors, higher numbers in the commit graph if they did a lot of work. If someone wrote 50 commits, and we squash it to 1 commit, it puts them low on the commit graph, when in fact they helped out more than what the graph portrays.

I would hope that such trivial thing as stats wouldn't contribute to degradation of master branch history. :) It's much easier to blame the code, revert changes or just read the branch history if it's all nice and tidy. Also it's beneficial when creating changelogs.
And creating a lot of commits should be discouraged in favor of creating more, smaller pull requests. :)

If it makes sense to squash it or merge, I am fine. I just prefer rebasing if possible because it usually makes the tree a little cleaner. But isn't always worth it.

Squashing implies rebasing I believe. So it has the clean look of rebased branch + clean branch history.

All in all, that's just my opinion and what I would apply to my project. I'm not gonna force anything in here, just stating my way of doing things. :)

[jisaacks]

@rchl that makes sense.

[deathaxe]

I totally agree with @rchl about squashing. I also like clean history in the end, so you can clearly see a relationship between issues and the resulting changes. Smaller fixes like in #331 in code style or commits which were created during a developement discussion don't need to be kept after merging.

[deathaxe]

I am quite far with my solution for Issue #26 which also brings along significant lower latencies to add the gutter icons especially for large files.

The work is mainly based on PR #338 which could maybe solve Issue #279 even though I am not quite sure with that. This issue might also be caused by empty output of git or an exception in update_git_file() which would be caught silently at the moment. With PR #344 we would at least get an idea of it, as some recommended exception handlings would print issues with git execution in this situation to console.

So can we check PR #338 and PR #344 and merge it, so I can prepare to propose the performance update?

PR #343 is splitted into several commits as it introduces some bigger changes I found useful to to act GitGutter somewhat smarter and clean up some cross references in the python modules. I guess a review of those changes takes a bit longer, so it is not so importand to have this merged, too.

But as the show_diff modue will change nearly completely to achieve the performance boosts it would make things easier, too. Otherwise I would need to resolve some conflicts with it later.

[rchl]

@deathaxe Sorry, but I've reverted a bunch of your latest fixes from master as they didn't have review. As said in this thread, all changes should be reviewed by at least one person.

And also those commits broke Mac and Linux + ST2 (I believe, looks like that from the code at least). Please resubmit those as pull requests and don't merge until reviewed.

[deathaxe]

Can you check PR #351, #354, #355, #356 for remaining issues, please?

I am nearly complete with preparing a PR to fix the following issues on top of those commits:

• Issue Distinguish untracked and ignored files #226: Show file status (commited, untracked, ignored) in taskbar by replacing git ls-files by git status
• Issue Ignore --assume-unchanged files? #233: git diff will no longer be called for commited, untracked, ignored files/views
• Issue Slow with copy and paste + huge files #147 / Fix issue: GitGutter ignores on_modified() event in ST2, because view visibility check fails. #349: Heavily reduced delays and removed flickering

[deathaxe]

Release strategy

@jisaacks: Continued discussion from #359

When calling the git: generate changelog it asks for the tag to compare against with the most recent one as default value. The changelog contains all short messages of all commits younger then the selected tag. If the short message is formated correctly and contain useful information the changelog is ready. In worst case you might select a couple of commits not worth mensioning in the changelog, what might be easier than look through the commits and pick commit messages manually.

As we will need to add pre-release tags like 1.5.0-pre1 or 1.5.0-rc1 GitSavvy will suggest the latest pre-release as base for changelog creation. I would prefere to add release messages to final releases only containing everything since the last real release. Pre-release tags may be simple tags only, while final releases use full annotated tags?

Tagging suggestion

1.5.0-pre1 - tag with maybe new features
1.5.0-rc1 - feature freeze for bug fixing only