Swiftgen: Cut a release to 3.0.2

[dostrander]

Hey i know there's a fix to a the swift3 colors template that fixes the line_length bug from swiftlint currently in master but could we cut a release so I don't have to have a custom template in my project? (I'm using carthage so I can't specify the version via the Podfile and have to use homebrew's version.)

More than willing to squash a few issues to expedite it too. Just point me to the ones you're looking to get in before next release :)

[AliSoftware]

I think #190 #192 #194 are good candidates to be included in such minor release. #175 seems ready to be merged too (but would probably entail a bump to 3.1 rather than 3.0.2)

[dostrander]

@AliSoftware great thanks! Will check them out tonight

[AliSoftware]

Wait, sorry, not #190, as this one changes the API of the generated code so might need a major version bump and probably not suitable for patch version

[AliSoftware]

Ok other PRs probably have similar issue so let's assume we'll do a bigger release than a patch one already ^^

[dostrander]

Sounds good. Another question, are we conforming to Swift3 api guidelines WITHIN the project? (aka enum names lowercased)

[AliSoftware]

We haven't migrated the internal code to Swift 3 yet sadly. That's a plan (I think I have owned an issue to trace that) though (migrating both to Swift 3 and update our internal API to confirm to guidelines too)

[AliSoftware]

It would be nice to include a fix for #174 in the next release, that should be a really trivial change to do (but don't forget CHANGELOG entries even for those trivial changes)

_PS: FYI I found back the issue about migrating SwiftGen itself to Swift 3, that's #169._

[AliSoftware]

You seem to have merged #194, which — by making the generated code more Swift 3 compliant, which is good — would lead to generated code incompatible with code generated by the current version.

That means incompatible API so I think we'll have to bump to a major version of SwiftGen. (Meaning that the other PR about removing tr()'s param name in Swift 3 can also be merged too!)

[dostrander]

Hey @AliSoftware have you been able to gauge how long it would take to move the project over to swift 3 (https://github.com/AliSoftware/SwiftGen/issues/169)? Though we technically might be able to do it under a minor/patch release it might be good to try to sneak it in with this major one, depending on the length of time it'll take.

The reason why I ask is I might be running into some time later this week/weekend and could try to spearhead that effort. Let me know how you feel about that.

[AliSoftware]

Hey @dostrander

I haven't even tried to convert, so I have no idea how small or big that migration would be.

The two big migrations pending in SwiftGen 's project are ported by #169:

• Migration to Swift 3
• Modifying the xcodeproj so it builds a .app (which would allow us to Cmd-R on the project to test it right from Xcode instead of having to rake install every time we want to test the CLI) — and adapt the rakefile accordingly when it re-packages the CLI for Homebrew & ZIP-ped releases — (The same way the SwiftLint project is configured, actually, from which we could take some inspiration maybe)

Not sure if we'd be able to tackle both in the same major release.

But technically neither of those changes would require a major release of SwiftGen (the migration to Swift 3 will probably mandate a major version bump of GenumKit itself, but since GenumKit isn't published to CocoaPods yet — which would actually maybe about time to do btw, see #9 — that's not as impactful as a major bump for SwiftGen itself).

So maybe it would be more reasonable to release a 4.0.0 with all the PRs and fixes you managed to merge recently, then start the migrations described in #169 after that, to avoid too much risks and do big changes step by step? (I don't mind doing a 5.0.0 if that's for Swift 3 support, I just don't want to do a major bump _just_ because there was a very simple change that we overlooked in the previous major bump, but I'm ok if it's justified)

[djbe]

@AliSoftware small side note related to GenumKit: I did make changes to it in #175 (added functionality), but forgot to bump it to 3.1.0. Or does it just follow the version number of SwiftGen?

If and when you want to release GenumKit as an actual pod, it'll probably have to move to it's own repo.

[AliSoftware]

@djbe I think that's the reason why I haven't published it on CocoaPods as its own pod yet, because semantic versioning is already hard as it is with SwiftGen (should we bump the version if SwiftGen's own code breaks compatibility, if the templates change in a way that the _generated_ code breaks compatibility, both? — So far it's both but it's sometimes hard to see in such a project, at least harder than with a regular pod). So having to do semver on GenumKit on top of all that would probably be even harder (except indeed if we publish it in a separate repo)

[djbe]

Honestly swiftgen is a tool that generates code, semver should only apply to that. I think that's what developers'd expect. How the tool is built shouldn't influence the version, except on major rewrites.

Separating GenumKit will probably ease your mind concerning internal code versioning :-)

[AliSoftware]

@djbe True. What I meant by "if SwiftGen's own code breaks compatibility" was more:

1. if we change the arguments and flags supported by the CLI or their behavior
2. or if we change the StencilContext's keys used by the templates, like renaming one of those keys, making templates of the previous version not compatible — even if that both generate the same code in the end when using the bundled templates, but would make custom templates which were based on the old keys fail

In case 1, only SwiftGen's version should be bumped, because SwiftGen itself is more just a CLI wrapper calling into GenumKit (GenumKit doing all the heavy lifting) but if the CLI change, only SwiftGen is affected. In case 2, both GenumKit (which is the one defining the StencilContexts and their keys, so the keys used by the templates) and SwiftGen (because that would make the custom templates not compatible) should see their version bump.

So even with separating GenumKit it's not that trivial to ensure we don't miss anything when releasing a new version anyway :wink:

[dostrander]

@AliSoftware That makes sense though I somehow convinced @ahtierney to start the migration over to swift 3 since he wanted to try to add some interesting code generation to swiftgen so we will see :). What else are we looking to get in?

[AliSoftware]

Idk, honestly seeing how I often postpone releases because "I just want to wait for this ruby feature… oh wait and this one… oh and damn now I'm busy and l don't have time to make a release anymore anytime soon…" I'm more and more starting to think that maybe it's better to release more often without waiting too much… even if there's a risk of major version bump afterward, rather than postpone it too much.

So maybe we should release 4.0.0 now even if other PRs are in progress and swear to beer ready soon otherwise we'll never release or wait too long. Nothing prevents us to do another release even soon after 4.0.0 if new PRs are merged soon after.

[dostrander]

That sounds good to me

[AliSoftware]

Are there any pending-but-really-ready-to-merge PRs we should merge before I release? (Like PRs only missing a CHANGELOG entry that we could add ourselves)

I might be able to do a release tomorrow evening, if I miss that schedule it'll be next weekend.

[dostrander]

198 is pretty much there. I gave it a once over a couple days ago and it looked pretty good. The only thing I really needed to check out is if he got all of the reserved keywords and if some of them don't have to be escaped (something like Foo.Bar.if )

[djbe]

Dunno how you feel 'bout #199? As far as I know there shouldn't be any breaking changes for current users, and fixes a broken swiftgen for users with namespaced folders.

[djbe]

Edit: I've created a milestone referencing the (still open) issues mentioned in this thread:

• #174: is already fixed, I've closed it if that's allright?
• #192: tests fail for now + still open discussion point about ordering
• #198: ready to be merged once tests pass
• #199: needs changelog entry

I've also added some closed pulls for easier overview, except #190. Small thing though: you've mentioned not wanting to release #190 due to breaking changes, but it's already been merged; same as #194 and #197, both of which are also breaking changes, right?

169 (swift 3 and app bundle) will probably be for later.

[djbe]

I've merged the remaining issues except #192, which still has a failing test (easily fixable). Shall we wait on it?

[AliSoftware]

I have plenty of stuff to prepare for a big party for a friend (on Friday) this week so won't have time to do a Release until this week-end, we still have a little time.

192 still might need some review (I haven't had time to read the code in the PR to ensure it's clean, and still not sure I like the double-parsing idea…) though, so I'd be ok to do 4.0.0 without it, as it can still make it in a 4.0.1 afterwards, so that should not be a blocker for the release imho.

[AliSoftware]

Hey guys,

Given that the migration to Swift 3 in #201 isn't as ready as we expected (still a couple of stuff to review) — and thus so is #204 which depends on it — what do you say we release a SwiftGen 4.0.0 now, without the migration of the project itself to Swift 3? After all, these can go into a 4.0.1 as it won't impact the external public API anyway, right?

[dostrander]

👍 Yep that's good with me

[djbe]

Sure. Think #192 could be included, or should we test it a bit more?

[AliSoftware]

Haven't had time to calmly review #192 after the last changes yet. Will give it a look.

[AliSoftware]

@djbe I've got just one remark on #192.

Up to you if you want to address it and merge it right away, or if you let the OP do it. If we let the OP do it, it'll probably wait for 4.0.1 (note that merging #192 would mean to rebase #201 afterwards anyway and migrate that new code, as #192 is in Swift 2 rn)

[djbe]

Hmm, #201 still needs some work, so updating that one if needed shouldn't be to much of an issue, especially since #192 doesn't change all that much.

If you give me a moment, I can merge it and create a new pull with the needed changes.

[AliSoftware]

Sounds great! have to review some more PRs in my other OSS repos, that should give your enough time :wink: 😛

[djbe]

no pressure 😆

[AliSoftware]

Good to go?

[djbe]

Jup!

[AliSoftware]

Released in CocoaPods, pending in Homebrew :tada:

[AliSoftware]

Maybe we should re-organize the GH Milestones now?

[djbe]

Sure.

Maybe create a milestone for what could be released in a minor version, and what should be delayed to a major release?

[AliSoftware]

Yup, probably like "Next patch (4.0.1)" / "Next minor (4.1.0)" / "Next Major (5.0.0)"

[djbe]

I don't know if it's useful to organise issues in milestones. PRs sure, because their impact can easily be measured (changes to files in "expected", changes to commands/arguments, ...)

[AliSoftware]

We could also do "Next Major" / "Next Minor" for PR, and "Urgent" / "Nice to Have" for issues?

I agree that issues are hard to categorise in milestones, you never know when it's gonna be ready.