Release Multi-Theme

[jgkamat]

The things in this PR have mostly been reveiwed already, I'm more looking for feedback on the release processes and finally getting multi-theme 'released'.

Closes #22

TODO:

• [ ] Verify this draft release looks good, which I think only contributors can see at this moment.
• [x] Update README to reflect new changes
• [x] Decide whether we will distribute generated CSS in git, releases or both. Right now, I'm thinking both is the safest solution.
• [x] Regenerate screenshots (?)
• [x] See what other people think. :)

[alphapapa]

Hey Jay,

Verify this draft release looks good, which I think only contributors can see at this moment.

The zip file appears to be corrupted. Weird.

Decide whether we will distribute generated CSS in git, releases or both. Right now, I'm thinking both is the safest solution.

I agree, let's do both. That way people who want to use the CSS but not make changes can clone and pull from the repo and get the CSS, rather than having to keep downloading archives or individual CSS files.

[jgkamat]

The zip file appears to be corrupted. Weird.

Ah, I think I found a bug where I sent the data of the zip file using the wrong flags, I've re-done the release and fixed the script, I think it should be good now.

[jgkamat]

Let me know if anything else should be added to the README, I think it's pretty good so far, but I could be forgetting something (and my writing is very far from perfect) :P

[alphapapa]

Thanks, Jay.

BTW, did we ever come to a conclusion about the project's name, whether we should have an organization, etc? I forget...

[jgkamat]

Nope, I don't think we did... I don't personally mind if we stick as is in this repo, rename this repo, or move the repo. Also see https://github.com/alphapapa/solarized-everything-css/issues/28 :P

[blu3r4d0n]

After almost a full day of usage I have no problems with the darculized css files

[jgkamat]

Ok, everything looks good to me, except two things:

1. what's a good demo site for bigblow @alphapapa, I'm not sure exactly what it refers to. Is this one ok?
2. The screenshots work mostly fine, but they're 6mb alone, so I'd rather not commit them directly.
3. Since ./screenshots was removed, the README pictures no longer work.

Once that's resolved, I think this is good to go (at least on master, and we can release some time after that) :P

[jgkamat]

@alphapapa, I've fixed the broken links to the screenshots by commiting the equivilant ones with the new format. I think we should figure out the proper way to distribute screenshot changes later on, because I'd like to get this in, after that we can do more incremental changes.

The github layout seems to just have been updated, so I wanted to start working on the updates for that...

I personally think this is good to merge, any objections?

[alphapapa]

Hey Jay, thanks for being so patient on this.

what's a good demo site for bigblow @alphapapa, I'm not sure exactly what it refers to. Is this one ok?

That one or https://github.com/fniessen/org-html-themes should be fine I think. Maybe linking to the repo would be better so people can see exactly what it is.

The screenshots work mostly fine, but they're 6mb alone, so I'd rather not commit them directly.

Hmm, that's an interesting problem. Ok, here's an idea: we could have a separate branch for screenshots, and only have one commit on that branch, and force-push overwrite its tip every time we update the screenshots, and link to the (long) GitHub URL for those screenshots in the readme in master. That way there would only be one set of screenshots ever stored in the repo, rather than growing by 6+ MB every time we update them. What do you think?

I personally think this is good to merge, any objections?

Let's do it! :) Thanks for your work on this.

[alphapapa]

We might want to automate the screenshots a bit more, e.g. automatically make a new commit with them, and then a pre-push hook to squash the screenshots branch when pushing. (It probably shouldn't squash before pushing, that way the still-current remote tip isn't overwritten locally until the user's ready to push.)

[jgkamat]

I decided to keep things as simple as possible, and instead of squashing the commits manually, I'm just amending them into the previous one. This also has the advantage of not relying on people to set up git hooks per instructions. Does this look good (see the last commit)?

I also discovered git worktree, which is perfect for this :)

[jgkamat]

I'm going to go ahead and merge this, I'll be happy to follow up with PRs if anything else is found that's broken... I'll think about making a github "release" after the css is updated for the new github layout.

[alphapapa]

Great, thanks, Jay. Yeah, git worktree seems ideal for this. I hadn't used it yet either. Great work.