Which development branch to use

I ran into an issue where SourceKit-LSP seems to fail in a variety of ways for any .swift file importing libgraphqlparser system lib (currently trying on MacOS but want this working in Linux too) even though compilation works as expected with the right linker flags. I'm assuming SourceKit-LSP needs to find headers / module map from some path or something where it's currently not.

I figure I could give debugging it a go myself here and see how far I get, but I'm not sure which branch to use for most expediency.

If I want a fix to be supported for swift 5.2, which was recently released, should I be developing from the branch swift-5.2-branch?

Thanks!

For development of sourcekit-lsp, I would suggest trying master branch first - it's not guaranteed to work with the 5.2 swift toolchain like the 5.2 branch is, but in practice I don't think there are any incompatibilities and it is the active development branch.

If I want a fix to be supported for swift 5.2, which was recently released, should I be developing from the branch swift-5.2-branch ?

I don't know if we would take additional changes on 5.2 at this point, since it is already released.

Is there a way to untangle development of sourcekit-lsp and swift? If swift ships a new version and sourcekit-lsp ships a new version and sourcekit-lsp has a bug are we expected to just live with that bug from then on?

1 Like

Would it be sufficient for to have a branch that is setup to work with the 5.2 toolchain that you can build yourself, or are you looking for separation of the releases? If a branch is sufficient, we could create a branch that automatically merges from master but that is setup to work with the latest released toolchain. We would still expect development to happen on master, but the new branch would make it more convenient to use with 5.2. This would be much more straightforward than separating the release process.

For clarity, my goal is to make it as most convenient as possible to onboard engineers onto the latest release version of Swift, some of who will be working on Linux exclusively and will be relying on SourceKit-LSP for likely VSCode. This implies that fixes to SourceKit-LSP issues should get to the developer on their (latest) release Swift asap.

I think that branch would work if we can also figure out a way to then have it build extensions for VSCode though I suppose that building an extension for VSCode will be a separate process on it's own.

Sorry, still wrapping my head around how a lot of this works, but it does sound like the process you suggested of having a branch that automatically merges from master would work as long as it also runs tests against the latest official RELEASE of Swift in CI (which now is 5.2).

Does that make sense?

Thanks!

Just to be clear, the same would apply to fixes to swift itself, or any other component of the toolchain. This is an argument for having more frequent releases of the toolchain, not for sourcekit-lsp specifically.

I think that branch would work if we can also figure out a way to then have it build extensions for VSCode though I suppose that building an extension for VSCode will be a separate process on it's own.

Could you expand on what you mean here by building extensions for VSCode and how that would be related to the branch?

Just to be clear, the same would apply to fixes to swift itself, or any other component of the toolchain. This is an argument for having more frequent releases of the toolchain, not for sourcekit-lsp specifically.

I don't follow how that's the case. SourceKit-LSP depends on SourceKit from Swift but not the inverse right? Additionally, Swift releases, I would imagine, will always happen more slowly and less often. That being the case, SourceKit-LSP could get fixes or enhancements on a faster cycle targeting whatever the most official release of Swift is that is out, improving developer IDE experience in a much faster fashion.

Could you expand on what you mean here by building extensions for VSCode and how that would be related to the branch?

VSCode has an "Extensions" tab where the developer can search for extensions as I'm sure you know. Extensions, from my experience, update automatically. I'm assuming then that extensions are normally built and packaged from a CI process and uploaded to wherever VSCode consumes them so that they can be easily searched and installed from VSCode. This would all happen automatically.

If the goal is to get fixes to developers faster, it's the same argument for any part of the toolchain. SourceKit-LSP is tied to the swift package manager version in the toolchain, so releasing separately from the toolchain is more complicated. I would like to someday address this by having a looser coupling to swiftpm, but it's not currently planned.

VSCode has an "Extensions" tab where the developer can search for extensions as I'm sure you know. Extensions, from my experience, update automatically. I'm assuming then that extensions are normally built and packaged from a CI process and uploaded to wherever VSCode consumes them so that they can be easily searched and installed from VSCode. This would all happen automatically.

Just to clarify: we do not currently build the vscode plugin anywhere in our automation.

Filed https://bugs.swift.org/browse/SR-12491 to create a master-with-swift-5.2 branch with a sketch of what we'll need to do.

Really appreciate this.

Re: VSCode, I see. There is a SourceKit-LSP extension that can be searched for in VSCode but looks like an outside party that runs that. Would it make sense to eventually integrate a CI step for this or do you think that will always be published by the community?

Having something like this in general would be desirable but we don't have a specific answer or plan of action at this point.

1 Like
Terms of Service

Privacy Policy

Cookie Policy