Earlier quoted context omitted.
[deleted]
Do you have any data / references to support this?
[deleted]
Releases – a workflow for shipping software to end users
51–60 of 82 posts
Re: Releases – a workflow for shipping software to end users
#52Any news on if/when an API for this is coming? Could be super useful.
I'm waiting for this too.
Re: Releases – a workflow for shipping software to end users
#53GitHub, thank you for this. Also, you used to have ZIP and Tarball downloads in the past, can you please bring back the Tarball downloads?
The tarball releases are still there...
Re: Releases – a workflow for shipping software to end users
#54It would be amazing to have public Releases from a private repo.
This, along with a separate/editable changelog (hidden commit log.) Some people manage a separate private repo, code review things over a period of weeks there, and then make a "release" by doing a single commit to the public repo with the final changes, minus any private keys/strings/etc.
Re: Releases – a workflow for shipping software to end users
#55Interesting that they launch this without API access and without adding it to the right hand nav. Sure, it's above your repo but I don't think that catches the eye enough and this is definitely meant to be a primary item users will be searching for.
Re: Releases – a workflow for shipping software to end users
#56I was a vocal critic when GitHub discontinued their downloads product earlier this year. I work on open source projects with compiled binaries. GitHub's answer to distribution had been "Use S3" which I never found satisfactory. As soon as they release an API, I'll be migrating all my projects over. EDIT: Just added my first release. Super easy. https://github.com/hawkthorne/tmx2lua/releases
Having the download buttons listed like that baffles me. Many downloads have similar names, and having them in a vertical list is far easier for determining which one you're supposed to get.
Re: Releases – a workflow for shipping software to end users
#57I was a vocal critic when GitHub discontinued their downloads product earlier this year. I work on open source projects with compiled binaries. GitHub's answer to distribution had been "Use S3" which I never found satisfactory. As soon as they release an API, I'll be migrating all my projects over. EDIT: Just added my first release. Super easy. https://github.com/hawkthorne/tmx2lua/releases
Which makes me wonder, since that wasn't all that long ago, why did they not give a teaser? Or did they, and we all missed it? Discontinuing the downloads was a big deal to a lot of people, which generated a non-trivial amount of bad press, but if they'd simply said "we have something better in the works" then I don't think anyone would've cared. Surely this wasn't dreamt up in between then and now...?
We don't talk about unshipped features as a rule. It's hard to do so in a way that doesn't imply promises or timeframes.
Re: Releases – a workflow for shipping software to end users
#58Earlier quoted context omitted.
[deleted]
Do you have any data / references to support this?
Not sure why he/she deleted their post, but for an excellent in-depth analysis of App Store pricing I thoroughly recommend Michael Jurewitz' 5 part blog post "Understanding App Store Pricing"
http://jury.me/blog/2013/3/31/understanding-app-store-pricin... http://jury.me/blog/2013/3/31/understanding-app-store-pricin... http://jury.me/blog/2013/3/31/understanding-app-store-pricin... http://jury.me/blog/2013/3/31/understanding-app-store-pricin... http://jury.me/blog/2013/4/1/understanding-app-store-pricing...
Theres a bit of Economics 101, and some very well explained real world data on app pricing. Essentially Michael's advice boils down to: try doubling your price. If you lose less than half your sales, you're now making more money than you were before.
Re: Releases – a workflow for shipping software to end users
#59Hmm, tried to draft a release. But after saving I'm only getting http 500 errors on the release page.
Shoot an email to support@github.com with a link to your repository. A 500 isn't an intended feature :)
Re: Releases – a workflow for shipping software to end users
#60Earlier quoted context omitted.
Which makes me wonder, since that wasn't all that long ago, why did they not give a teaser? Or did they, and we all missed it? Discontinuing the downloads was a big deal to a lot of people, which generated a non-trivial amount of bad press, but if they'd simply said "we have something better in the works" then I don't think anyone would've cared. Surely this wasn't dreamt up in between then and now...?
Still, why would you get rid of it in the first place just because something is better on the way? IIRC their reasons for getting rid of it had to do with not being a distribution center and focusing strictly on the source code development. It probably wasn't just "dreamt up" but more likely they found new reasons why it should complement their future business model.
We thought the Downloads feature was doing more harm than good in its previous form. Quality-wise it just wasn't up to snuff (failed frequently, flash, lack of design). Bad experiences on the site need to be fixed or killed. No one was willing to dedicate time to fixing it because they felt their time was better spent on other things so that left killing it.
The timing of the Releases feature only entered into the decision a little bit. It's hard to tell when something is going to ship at GitHub because there's no deadlines. Projects are done when they're done. The downside to this approach is that you can't rely on ship dates when making decisions like when to kill a feature something might replace.