Release script

[guillermooo]

@rojepp Does this look ok as a release script? The releases repo can be changed to any location, but as it should be read-only for everybody else, I don't think it matters much?

[rojepp]

Good work! The script worked for me on OSX. This may be prettier if it used fakes git helpers, wouldn't need to mess with cd'ing here and there.

Also, I think it kind of does matter where the repo lives. It is important to give the project a sense of community-owned, and I believe everyone who installs this plugin will see this url, no? I know @dsyme has strong thoughts about this. :)

I'd suggest renaming this repo to 'fsharp/sublime-fsharp' and make a new repo for publishing: 'fsharp/sublime-fsharp-package'. What do you think?

We'd probably need to get someone with sufficient access rights to fix this for us.

[rojepp]

Also, the rules at https://packagecontrol.io/docs/submitting_a_package need to be looked at closely. For instance, it would seem this package needs a '.no-sublime-package' because it includes executables?

[rojepp]

CI failure: It is doing build.cmd install which makes release target run, this is not right. Dependencies should probably be

"Clean"
    ==> "Build"
"Build"
    ==> "Release"
"Build"
    ==> "Install"

[guillermooo]

Good work! The script worked for me on OSX. This may be prettier if it used fakes git helpers, wouldn't need to mess with cd'ing here and there.

Prettier is better. Will change.

Also, I think it kind of does matter where the repo lives. It is important to give the project a sense of community-owned, and I believe everyone who installs this plugin will see this url, no? I know @dsyme has strong thoughts about this. :)

@dsyme @rneatherway @rojepp

Users won't likely see the url but they certainly could. It's also more consistent to have everything in one place. Someone should set up the repo and grant me R+W access, I guess.

I'd suggest renaming this repo to 'fsharp/sublime-fsharp' and make a new repo for publishing: 'fsharp/sublime-fsharp-package'. What do you think?

Works for me. But the releases repo should never be used by anybody except devs, so giving it the sublime-fsharp-package-releases is more explicit IMO. Either name is fine by me, though.

[guillermooo]

Also, the rules at https://packagecontrol.io/docs/submitting_a_package need to be looked at closely. For instance, it would seem this package needs a '.no-sublime-package' because it includes executables?

Noted, will investigate.

[guillermooo]

CI failure: It is doing build.cmd install which makes release target run, this is not right. Dependencies should probably be

Thanks. Will change.

[rneatherway]

I host the emacs release repo under my personal account for convenience, I don't have any strong feelings on the subject. I was looking at making the emacs mode download fsautocomplete after install rather than bundling it in the package, which would allow using the code repo for releases as well, but emacs can't handle archives in a neat cross platform way. On 4 Jun 2015 18:35, "Guillermo López-Anglada" notifications@github.com wrote:

CI failure: It is doing build.cmd install which makes release target run, this is not right. Dependencies should probably be

Thanks. Will change.

— Reply to this email directly or view it on GitHub https://github.com/fsharp/sublime-fsharp-package/pull/27#issuecomment-108984890 .

[rojepp]

Naming of the two repos is not that important. My thinking was to have the shorter url for participation. There should maybe be a readme in the generated repo for linking to the dev repo.

[guillermooo]

Naming of the two repos is not that important.

Same here, but I think consistency is also good. If for other editors development happens in "xxx-fsharp-yyy", I think "sublime-fsharp-package" is more similar. But I'm just trying to find a reason to sway me one way or the other. I really don't care that much.

My thinking was to have the shorter url for participation. There should maybe be a readme in the generated repo for linking to the dev repo.

I'll make sure to add some notice, yup.

[rojepp]

@rneatherway It would still download a specific version, so why add complexity to the state of the plugin? It seems likely to increase the failure rate. Some solve it by pushing to a specific release branch in the same repo. I find that somewhat confusing, especially when release branch is master.

[rojepp]

@guillermooo It would be nice if you were on fsharp.slack.com. A bunch of 'tooling' discussions there. Are you on twitter?

[guillermooo]

@guillermoooo on Twitter (there's another dev by (at)guillermooo there and I think he's tired of getting mixed up with me for ST stuff :). I'm just a lurker, though. And someone would have invite me to Slack, I believe (guillermo.lopez(at)outlook.com). I'm in a couple of orgs already, but I don't participate much because it's too instant and distraction potential is high. Anyway, would be glad to join; it's definitely useful!

[rojepp]

I think you get an invitation when joining fsharp.org. (it's free)

[guillermooo]

Hm. I think I'm a member to fsharp.org already. I may have used a different email address. Will check.

[guillermooo]

@rojepp Now really joined the Foundation. Didn't get any Slack invite that I can see.

[rojepp]

Ah apparently this is still done manually. I've asked Reed to send you one.

[guillermooo]

@rojepp Can't get the commented out part of the release target to do what I want. PTAL.

[rojepp]

I heard you like Pull Requests, so I made a Pull Request for your Pull Request. :)

[guillermooo]

Excellent, thanks! :)

[guillermooo]

Seems to be working great! We are ready for making a first release to PC, minus a few last touches.

What should we do about the release URL?

a) We change it to some repo under this org. b) We keep it forever outside of this org. c) We keep it where it is for now so that we can make a release now, then decide about its future later. d)

[rojepp]

I suggest c. Changing it later is only a PR away. I think this is ok to merge, and you can then make a PR for package control?