New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Branching/tagging/supported setups policy #23
Comments
Having at least tags would be very useful personally as I'm RPM-packaging this for Fedora (privately at the moment, but I don't mind potentially making them public in future). RPM spec files need a source archive URL, and GitHub generates semantically named tarballs for tags, instead of commit-named zips, e.g.: https://github.com/kurogetsusai/firefox-gnome-theme/archive/v58.0.tar.gz vs. |
Actually I've been thinking a bit about this, we already have support for Firefox 57, Mozilla isn't gonna change that version anymore, so it's mostly stable, but we might want to still fix some minor bugs and add new features like the code you wrote for private windows, URL bar autocomplete etc, so tagging the "last supported" version of this theme for a specific Firefox version wouldn't be much helpful from my point of view. I'd like to avoid using separate branches for each Firefox version, I worked on a few projects which did that and the merge commits were a real pain, it's hard to keep track of merging a specific feature to specific branches and not end up with more merge commits than normal commits. So no branches. Another problem I noticed is the If you want nice tarballs from GitHub, I can release a 1.0.0 version after I resolve this and #18, and #21 and after that we will just follow the semver specs and release a version from time to time. Does it help you with these RPM packages? I have no idea how they work, so I'm not sure. And finally about our standard setups. I'll define something later, but the general idea is we support all released (so no beta / nightly) stock Firefox versions, if some distros have their own patches like Fedora (which will disappear soon, after FF 59 gets released), we might support them too, but I can't debug Firefox in a VirtualBox, so I probably won't be able to do much. I'll count on other contributors, Rafael wrote most of our CSD support for Firefox 57 since I wasn't able to run Fedora. I'm also not sure if my soon-to-be-commited FF58 fixes are gonna look good on Fedora, so I'll need someone's feedback again. Also I can't write themes for every new GNOME version. I'll do what I can, but it would be nice if other people contributed too and wrote themes for their GNOME version if they want it. And we support only normal theme density. I'll write a |
No AFAIK 57 is now obsolete/unsupported (since the moment 58 was released). No distro should be continuing to provide 57.x releases (unless they're effectively making a custom downstream ESR for some dumb reason ;)), they should either have upgraded to 58, or be using ESR (52). I'd suggest dropping support for obsolete and potentially vulnerable Firefox versions immediately, and focus on latest/ESR only, i.e. currently 58 and 52. That would also allow for a pretty simple branched setup, at most ESR, current, next.
Presumably there's no ongoing performance penalty, just a probably minuscule bit extra startup time. Seems like a decent idea in general, as long as the divisions end up maintainable without grey areas.
Just annotated tags is fine; GH's "release" thing isn't necessary (it's a proprietary GH feature too, not a standard Git thing).
It's doable as is (already packaged it via a commit snapshot zip); having a tarball URL that corresponds to a version rather than a commit ID just makes it a bit nicer. Having a version (i.e. annotated tag for tarball purposes) that maps to the Firefox version also makes packaging simpler, since you just bump the version of the RPM spec. file (58, 59 etc.) and set it to depend on firefox-$version, source at github/blah/$version.tar.gz etc. With a simplified version support/branching approach (ESR+current), I really think that following Firefox versioning is the way to go, since it's more semantic in this case than semver ;)
What distro/GNOME/Firefox are you on? Ubuntu 16.04 LTS/GNOME 3.18/Firefox 58 at a guess? What sort of debugging are you trying but unable to do? Have you tried in virt-manager or gnome-boxes (i.e. KVM)?
That's why I suggested just latest GNOME plus whatever Ubuntu LTS is on (since Ubuntu is the old/mangled-GNOME-shipping 800 lb gorilla... :J) |
Ok, so I decided. Old versions will get tags (I'll tag what we have now as
Yes, except I'm still on Firefox 57.
Just opening the inspector for the browser's UI (ctrl+shift+alt+i when remote debug is enabled), I only tried VirtualBox so far but I'll try something else when i have some time. Also when FF58 becomes obsolete, this won't be necessary anymore, since other distros just ship stock FF and Fedora's only reason to patch it will disappear too, since FF59 supports CSD, so it's not an important issue anyway. |
Per #21, would be useful to have tags for specific versions, and a policy for what master tracks (nightly? beta? release?)
Tags would be e.g. 58.0 for the release of the theme for FF58, then 58.1 for the first bugfix release of the theme for FF58 etc. Fixes for "old" versions of Firefox (i.e. FF versions older than whatever master tracks) would go into version-specific branches.
So maybe master applies against nightly, then there's a 59 branch and a 58 branch.
As mentioned on #21, Fedora's CSD backports can be detected so don't need a separate branch.
Also, would be good to have some definition of a "standard" setup the theme is tested against - Adwaita Light/Dark desktop theme (not "global dark"); normal Firefox theme density; fresh Firefox profile; supported toolbar layouts; supported GNOME version(s); supported distributions. There are a few "fuck knows why this doesn't work for some people, twiddle with this stuff randomly to get it work" things in the theme at the moment.
For distros tested against I'd suggest at least Ubuntu and Fedora - Ubuntu since it's the behemoth, Fedora because it pretty much offers standard/latest GNOME vs. Ubuntu's mess of old versions, GNOME patches etc. etc. The Firefox CSD patches/backports are unusual, Fedora doesn't usually do early downstream stuff like that.
For supported GNOME versions I'd suggest latest release + maybe current Ubuntu LTS GNOME version (again, the behemoth factor).
The text was updated successfully, but these errors were encountered: