Right, so we're nearing the point to release SwiftGen 5.0, the remain issues to tackle are:
[x] Update documentation/templates (#305, https://github.com/SwiftGen/templates/pull/59)
[x] Release StencilSwiftKit 2.0 (https://github.com/SwiftGen/StencilSwiftKit/pull/55)
[x] Release templates 2.0
[x] Update SwiftGen documentation with new commands/options/templates and sample output (#314)
CHANGELOG entries esp after the last PRs we did recently in a rush (#321)master (#321)SwiftGenKit & StencilSwiftKit after all those last-minute hot fixes?swiftgen locally (as we still don't have unit test for the CLI layer), like rake cli:install + ./build/swiftgen/bin/swiftgen -v, ./build/swiftgen/bin/swiftgen list templates, etcrake changelog:reset on all repos@AliSoftware That should cover it, I think? I'll keep this up to date so that we can have a step-by-step todo list of what remains to be done.
:wave: @djbe !
Trying to find some time during my train home to work back on SwiftGen so that we finally make that 5.0 release. Do you think that list is still up-to-date?
Hey man, sorry about the inactivity, been busy moving houses (still am) and no internet.
The list should still be up-to-date. The only thing I'd like to review before we do a release is https://github.com/SwiftGen/templates/issues/60. Depending on our decision there, we might wanna review our system of "only enum cases" when user might want to enumerate.
No worries, I've been inactive for weeks too between vacation and house stuff too.
Will look at all that 👍 probably won't address everything today but let's start somewhere ;)
Next time we might want to use GitHub's Projects (either on Eve or on SwiftGen's repo) to handle those kind of lists for releases instead of an issue?
Yeah, might be easier. How does cocoapods manage such things (they also have multiple repos)
AFAIK, via slack and the technique of everything-is-in-the-core-contrbutors-heads 😆
Hi guys. Is there an ETA on the 5.0 release?
Hey @yonaskolb
Sorry for the delay. My personal and professional lives are super busy lately, I didn't forget about 5.0 but it seems that there's always some news in my life those days that were not predicted and make me not have enough time to take care of my OSS work. Sorry for the inconvenience. Well try to finish this ASAP though.
Same here, been moving houses, and stuck with no internet (at home) for 2 weeks 😱
We'll try to coordinate a release when possible, and if any minor bug fixes pop-up, we can always include those. New features are delayed until 5.1, otherwise we'll never get there.
Will SwiftGen 5.0.0 support Xcode 9 and swift 4? These might be a stupid question but I am trying to use SwiftGen 4.2.1 in Xcode 9 beta 3 but it didn't work. Thank you for any suggestion.
Hi @csnu17, could you please give some details on what did not work for you?
On my side, I can confirm that it works for localizations and fonts with Xcode 9 beta 3 using swift 3, I did not try with swift 4 though.
I forgot to mention but you should give us those details in a dedicated issue.
Thanks!
@Liquidsoul it works with Swift 3.2 compiler but no for Swift 4.
@csnu17 so this means is not a problem with SwiftGen 5.0 (the tool), it just means that we'll need a dedicated template for Swift 4.
As @Liquidsoul said, this issue is about the SwiftGen 5.0 release tasks, not about adding a Swift 4 template. Please open a dedicated issue — preferably in the dedicated SwiftGen/template GitHub project then, as it's about adding a new template — to discuss the addition of a Swift 4 template, ideally explaining what error you have when you generate code with the Swift 3 template and try to compile it using Swift 4 so that we see what we'll have to adjust between the Swift 3 and Swift 4 template.
Also note that because SwiftGen is based on templates (and that's one of its main advantages), you can create your own templates without waiting for new SwiftGen releases, so you can easily create your own Swift4 template to fix the errors you see in your project and use that custom template even before we have time to integrate a Swift 4 template ourselves bundled in the next release anyway. See the documentation in the templates repository to learn more about creating your own templates for your projects: it's just a matter of one command line to execute to duplicate an existing template then adjust it to your needs so you're not dependent on a new SwiftGen release for that.
It seems that we forgot to add a CHANGELOG entry for https://github.com/SwiftGen/SwiftGen/issues/39#issuecomment-306368561 at some point
Yeah, https://github.com/SwiftGen/templates/pull/49 is missing a changelog entry. https://github.com/SwiftGen/SwiftGenKit/pull/41 correctly has one though.
I see CHANGELOG entries for both templates and SwiftGenKit (how did I miss both of them when searching earlier… I might need another coffee ☕️ [EDIT]Oh I know I searched for "strings"—plural— not "string" 😝 )
It's just an entry/feature that we might want to report on SwiftGen's own CHANGELOG as part of the "big changes from other repos" section.
Oh wow, I didn't even check the actual changelog file, directly dove in the PR and commit histories 🤦♂️
Yeah, definitely include it in the main repo changelog.
Seeing all the activity on here the last few weeks, it seems quite a bit of work to sync up all these different repos. I'm curious as to the reasoning for taking such an approach over a mono repo? Have there been some good benefits?
@yonaskolb It was originally as a request by @krzysztofzablocki for https://github.com/krzysztofzablocki/Sourcery to be able to share StencilSwiftKit between SwiftGen and Sourcery.
(tbf I've seen some Stencil extensions implemented in Sourcery directly instead of shared in StencilSwiftKit, so we ought to be better at using this shared framework at our advantage yet)
So indeed that's a good point, so far it has been more of a hassle to maintain that as a multi-repo, and I sometimes think that it maybe wasn't worth to split it. But now that we have https://github.com/SwiftGen/Eve and improved the rake tasks and automation, I hope we'll become better at it…?
Ok fair enough.
As long as you know it's possible to have multiple modules in a package, when can then be linked to separately as dependencies.
For example in a project I have which has a similar "Kit" library https://github.com/yonaskolb/XcodeGen I have a seperate XcodeGenKit module that is designed to be used as a dependancy in other packages
@yonaskolb Thanks for the tip. What I don't like with that approach is that it requires all the files of a given module to be listed flat in a single folder. And given how SwiftGen source code is organised and split I like having some FS structure if possible…
You can't have a hierarchy to organise your files in the filesystem without automatically creating a SwiftPM module, right? (or maybe you can if SwiftPM only create modules for top level folders in Sources/ but not for subfolders?).
I'm not using SwiftPM yet (we've just organised the git repo in a way that would probably allow us to do so in the future, but we haven't checked if the project still compiles using SwiftPM — rather than just Xcode+fastlane like today — so we should definitely investigate that at some point — but probably once SwiftPM is more stable and iOS-modules-ready?)
Hi @AliSoftware, yes I should clarify of course, this is with Swift Package Manager.
You can though in fact have code organised in multiple folders, it doesn't have to be flat. As you say, the top level folders define the modules but you can have any sort of structure you like within those. For example here https://github.com/yonaskolb/SwagGen/tree/master/Sources/Swagger.
With Swift 4's package manager that layout will become even more flexible as you explicitly define where sources reside.
I'm not advocating that you move to a mono repo or Swift PM, was just curious of the reasons for the decision to split up the codebase.
No worries, I appreciate the interesting feedback 😉 thanks for this information!
We might at least want to re-check for SPM compatibility some day as I haven't tested that it still works with SwiftGen repo in a while. We could then at least reorganise the folders to ensure proper modules split s interpreted by SPM
Only "problem" left with monorepo and keeping all the modules in a single git repo is that projects depending on StencilSwiftKit will have to come the whole repo just to use only one submodule. But maybe not that big a deal after all…
Well in my opinion I think StencilSwiftKit could actually stay in another repo as it's fairly independent. I think the more logical grouping would be SwiftGen, SwiftGenKit and Templates, as they are very related and can't really be updated independently
As you say if any one of those pieces wanted to be used as an isolated dependency a checkout of the whole repo would be needed. But with Cocoapod subspecs and Swift PM modules, I don't think that's really an issue. People wouldn't link to stuff they don't need, they would just have a slightly bigger initial checkout.
Yeah you're probably right I'm actually kinda rooting for that solution, makes sense…
We'll see about it later, after 5.0, + after Xcode 9 & Swift 4 support has landed afterwards (colors in assets catalog & Swift 4-compatible templates are a priority after 5.0) but I'll definitely keep that idea in mind for future organization!
Waiting for https://github.com/Homebrew/homebrew-core/pull/16727 to be merged :wink: