search

wyantb / HashMask

A browser addon for password fields, adding a visual hash to aid in memorability.
5 stars 0 forks source link

Rename "master" branch to "chrome"? #50

Closed nickserv closed 11 years ago

nickserv commented 12 years ago

I think this would be a good idea, since:

  1. We don't want to make it look like the Firefox port is significantly less important development wise.
  2. It's more descriptive and less confusing, especially for a project that's going to be available for multiple browsers.
  3. We can change the default branch on GitHub, and renaming our default branch shouldn't break anything as our repo links to the default branch anyway, it's not glued to "master".
wyantb commented 12 years ago

I disagree. I don't want the firefox branch to exist in the end, negating all of points 1/2/3. 'master' should ultimately have working FF code, Chrome code, etc code. It's not at all a problem if we need to make a few quick makefiles to shuffle around the files for each browser into a directory / zip / whatever that comes prepared for that browser, and thus we can develop things in whatever directories we want until that point.

nickserv commented 12 years ago

Ah, I see what you mean. Personally, I think that's a good idea for distribution, but I think it could make development more annoying (not just for the initial Firefox port, but for future updates as well). When stuff's in branches like it is now, we can make changes that effect both Firefox and Chrome into the Chrome branch, and then merge them into Firefox later.

Could we maybe do hacks with patch files to achieve something like this with directories instead of branches? It'll probably still require more manual labor than branches, but at least some of it could be automated. Also, we could write scripts/makefiles for merging if need be.

wyantb commented 12 years ago

In my mind, we have three directories. Common, FF, and Chrome. As much stuff as possible should be in the common directory (libs, inject.js, etc).

Anything that actively differs between the two goes into their separate directory. And that stuff can't be auto-merged anyway, because that's implicitly stuff that's based on the particular browser APIs.

Then, we have a Makefile (see the start of one I have already) with an 'all' target that depends on 'chrome' and 'ff', each of which copies things into build/ff or build/chrome, matching the directory structure that the two types expect.

Do you get what I'm intending here?

nickserv commented 12 years ago

Ah, that makes sense. Feel free to close this issue.

nickserv commented 12 years ago

By the way, do you want to do that for 2.0 or for a later release?

wyantb commented 12 years ago

I'll probably jump to 2.0 when we have a FF release, because why not. Other than that...it's internal directory structure changes. There's no reason to do it now, or delay later. I'll do it once we're ready to do it. Just inviting merge problems if I stake out a claim of when I'll do it.

wyantb commented 11 years ago

No real reason to keep this one around; closing.