search

eclab / edisyn

Synthesizer Patch Editor
Apache License 2.0
547 stars 51 forks source link

Use Github releases #8

Closed joshka closed 4 years ago

joshka commented 5 years ago

Hiya,

I just pulled a copy of the repo and noticed it's fairly large (1.1Gb) due to the many versions of the Jars and macOS application files. You might not be aware of the Github release tab approach, but using it will help prevent that growing: This is available in this repo at https://github.com/eclab/edisyn/releases.

I would like to also contribute a continuous integration build approach using Travis CI, so this can be automated and simple to continue for you to continue releasing in this fashion, as it becomes as simple as the following to release a new version:

git tag v18
git push --tags

Thirdly related to this, I'd suggest stripping out all the existing jars and installers from the repo. This is a somewhat destructive change as it changes history, but this is a good thing as it makes it easier for others to contribute changes. If you go down this path, you may want to take a copy of those files to ensure that you can repro bugs in older versions if that's something you care about.

I'm happy to show what this looks like to demo the benefits if you're interested (i.e. strip large binaries, setup CI build, setup a release page). My ulterior motive is to end up being able to install this just via Homebrew. E.g: brew install edisyn

Anyway, thanks for releasing this. I'm looking forward to using it to program a TX81Z I recently picked up.

eclab commented 5 years ago

It is a problem, you're right. But the real reason is not what you think. The real reason is that I don't use git. I use svn.

Don't tar and feather me yet. Mercurial is my dvcs of choice: git drives me nuts. So on github I use svn. The problem is that github's svn->git bridge is broken in several ways, and one big on is that it doesn't understand how to do binary diffs properly, so what is a very small svn repository becomes a massive git nightmare.

Because I've been working on Flow a lot the last month or so, I've been avoiding the clear thing I have to do soon -- blow away the repository history and start with a new one. But I'll have to do it soon, and just store the jars and OS X apps and (a big one) the pdf docs as binaries hosted on my own site. :-(

If you're hoping to port to brew, you'll have a problem: recent versions of OS X are fairly hostile to raw jar files except as launched from the command line. That's why Edisyn has to be distributed as a ginormous binary for OS X, instead of a svelte little jar file. Otherwise all you have to do is grab the jar file and say java -jar edisyn.jar.

On Nov 17, 2018, at 8:48 PM, Josh McKinney notifications@github.com wrote:

Hiya,

I just pulled a copy of the repo and noticed it's fairly large (1.1Gb) due to the many versions of the Jars and macOS application files. You might not be aware of the Github release tab approach, but using it will help prevent that growing: This is available in this repo at https://github.com/eclab/edisyn/releases.

I would like to also contribute a continuous integration build approach using Travis CI, so this can be automated and simple to continue for you to continue releasing in this fashion, as it becomes as simple as the following to release a new version:

git tag v18 git push --tags

Thirdly related to this, I'd suggest stripping out all the existing jars and installers from the repo. This is a somewhat destructive change as it changes history, but this is a good thing as it makes it easier for others to contribute changes. If you go down this path, you may want to take a copy of those files to ensure that you can repro bugs in older versions if that's something you care about.

I'm happy to show what this looks like to demo the benefits if you're interested (i.e. strip large binaries, setup CI build, setup a release page). My ulterior motive is to end up being able to install this just via Homebrew. E.g: brew install edisyn

Anyway, thanks for releasing this. I'm looking forward to using it to program a TX81Z I recently picked up.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

joshka commented 5 years ago

Don't tar and feather me yet.

:) No tar or feathers necessary. I was a big hg fan many years back, and before that svn. These days I do much prefer git (maybe I can convince you to drink the cool aid ;)). Either way, thanks for the heads up that your process is a little different to what I'd assumed. At a guess, svn will definitely prevent me from doing the repo filtering easily, so I'll leave that bit for now.

If you're hoping to port to brew, you'll have a problem: recent versions of OS X are fairly hostile to raw jar files except as launched from the command line.

I definitely would prefer to keep it running as an app rather than a naked jar as this plays nicely with the standard app launcher approaches in macOS (spotlight / Alfred etc.). The main blocker to getting edisyn on brew that I saw, and my trigger for all of the above, is having a versioned URL for the cask to download from. Hence why I wanted to move this to the releases approach. CI is not too much effort more at that point (e.g. https://github.com/joshka/junit-json-params/blob/master/.travis.yml) I've previously written quite a few casks for Homebrew, as well as contributed to the core, and my day job is heavy on the java, so I'm optimistic that this is feasible.