search

CoatiSoftware / vs-sourcetrail

Visual Studio Extension to communicate with Sourcetrail and generate a JSON Compilation Database from a Visual Studio Solution
Apache License 2.0
118 stars 43 forks source link

Fix warnings #24

Closed dakotahawkins closed 7 years ago

dakotahawkins commented 7 years ago

Fixed everything VS complained about.

mlangkabel commented 7 years ago

Thanks for taking the time to fix these warnings. I think the warning about closing the socket twice was a real thing that actually happened sometimes!

We really appreciate your work on this project and we'd like to offer giving you collaborator access to this repository. This means that you would be able to create branches directly on this repository so you wouldn't have to sync your fork everytime something changes. However, we'd still ask you to issue pull requests for your changes because that provides the tools for talking about the changes before merging them.

dakotahawkins commented 7 years ago

@mlangkabel Sounds good to me. If it's OK with you I'd like to work out establishing some kind of "next" branch (that's what git calls theirs, the name isn't important to me) where things like my include paths change could live after they're reviewed but before they're part of an official version.

mlangkabel commented 7 years ago

For the internal software development at @CoatiSoftware we use a different branching concept, but why not. We always like to try something new! I think this article has a good description of what you are proposing (but we'll only need the master, next, release, and some feature branches ;) )

dakotahawkins commented 7 years ago

We use the git flow branching strategy at work, and while it works very well we do have a massive codebase and need more than 1 long-lived release branch at a time.

I'm not sure this repo quite warrants all of that, but some easier way to get at the bleeding edge code might be good for interested users.

I really wish the extension gallery supported differentiating between stable and beta versions, so people could opt-in to those kinds of updates.

mlangkabel commented 7 years ago

Sure, lets keep it simple for this project. So we use the next branch for merging reviewed updates and features while the master branch has one merge-commit for each release.

But I think that having short-lived release branches is a good idea, too. They should branch away from the next branch whenever we want to make a new release. These release branches should have commits for changing the version number and updating the changelog and get merged into master (for the actual release) and also back into next (to keep the changes to the version number and the changelog for the following releases).