Releases #869

Activity

1. adamgit commented on Jan 26, 2026

   

   adamgit

   on Jan 26, 2026 via email

   Contributor

   More actions

   No plans to change anything - as an open-source project all work only happens because someone needs it themself, or donates their time. I'm too busy at the moment to be creating extra work I don't need! IF someone stepped up to manage releases I'd support them, but if they're going to half do it and then bail, or try to avoid most of the work (e.g. by not compiling a list of contributors) then I wouldn't support them. Better to leave it as-is than to do it badly.

   …

   On Mon, 26 Jan 2026 at 20:26, Eduard Miniakhmetov ***@***.***> wrote: *kapitoshka438* created an issue (SVGKit/SVGKit#869) <#869> Dear @adamgit <https://github.com/adamgit> First and foremost, I would like to express my sincere gratitude to you, for all the tremendous work and dedication you put into developing this project. I can see that this project is actively being developed. However, I don't quite understand the stable release policy. The last stable release 3.0.0 was published almost 4 years ago. Are there any plans to reconsider the release cycle? For serious large-scale applications, pinning dependencies to some commit in an actively developed unstable branch is unacceptable. I suggest considering the possibility of releasing versions with some regularity, with tagged releases and Release Notes. I understand the difficulties you described in this comment <#853 (comment)>, but nowadays it's not difficult at all to leverage AI to set up automation once and handle all the subsequent release processes. — Reply to this email directly, view it on GitHub <#869>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACHL6LQSRJ3H6I6IOXAXI34IZZ57AVCNFSM6AAAAACS6OF2GKVHI2DSMVQWIX3LMV43ASLTON2WKOZTHA2TONJTGAYDONI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

   ❤️React with ❤️2Reacted by Eduard Miniakhmetov and Martin Umgeher
2. adamgit commented on Jan 26, 2026

   

   adamgit

   on Jan 26, 2026 via email

   Contributor

   More actions

   Probably the two biggest pieces of work for a release today would be: 1. Evaluate the current latest commit for changes that are less stable, in particular recent changes around a. the logging framework and/or making it more modular, and b. the way files are #include/#import which has caused recurring problems on some build platforms but not others. 2. Test on each of the platforms and make sure everything builds correctly out-of-the-box with latest Xcode, at least in simulators, but ideally also on devices. ... so that the release can be marked as 'we know this works, for all builds, all platforms, and contains no code that's about to rollback/change in major ways, you can rely on it'.

   …

   On Mon, 26 Jan 2026 at 20:36, Adam Martin ***@***.***> wrote: No plans to change anything - as an open-source project all work only happens because someone needs it themself, or donates their time. I'm too busy at the moment to be creating extra work I don't need! IF someone stepped up to manage releases I'd support them, but if they're going to half do it and then bail, or try to avoid most of the work (e.g. by not compiling a list of contributors) then I wouldn't support them. Better to leave it as-is than to do it badly. On Mon, 26 Jan 2026 at 20:26, Eduard Miniakhmetov < ***@***.***> wrote: > *kapitoshka438* created an issue (SVGKit/SVGKit#869) > <#869> > > Dear @adamgit <https://github.com/adamgit> > First and foremost, I would like to express my sincere gratitude to you, > for all the tremendous work and dedication you put into developing this > project. > I can see that this project is actively being developed. However, I don't > quite understand the stable release policy. The last stable release 3.0.0 > was published almost 4 years ago. Are there any plans to reconsider the > release cycle? For serious large-scale applications, pinning dependencies > to some commit in an actively developed unstable branch is unacceptable. I > suggest considering the possibility of releasing versions with some > regularity, with tagged releases and Release Notes. > I understand the difficulties you described in this comment > <#853 (comment)>, > but nowadays it's not difficult at all to leverage AI to set up automation > once and handle all the subsequent release processes. > > — > Reply to this email directly, view it on GitHub > <#869>, or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AACHL6LQSRJ3H6I6IOXAXI34IZZ57AVCNFSM6AAAAACS6OF2GKVHI2DSMVQWIX3LMV43ASLTON2WKOZTHA2TONJTGAYDONI> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> >
3. benthomas-carsales commented on Jun 1, 2026

   

   benthomas-carsales

   on Jun 1, 2026

   More actions

   It would be great to see a return to the healthy open source practice of creating releases on a more regular basis.

   👍React with 👍1Reacted by Igor-Palaguta
4. adamgit commented on Jun 5, 2026

   

   adamgit

   on Jun 5, 2026 via email

   Contributor

   More actions

   Poorly phrased demands from people who don't understand the issues, and who are contributing nothing, make things worse not better (the time it cost me to read and reply comes out of the time I could have spent doing something useful). If your team genuinely doesn't know what a commit-SHA is then I suggest they look into that before worrying about nebulous releases (that they're not willing to do any work to achieve).

   …

   On Tue, 2 Jun 2026 at 00:02, Ben Thomas ***@***.***> wrote: *benthomas-carsales* left a comment (SVGKit/SVGKit#869) <#869 (comment)> It would be great to see a return to the healthy open source practice of creating releases on a more regular basis. — Reply to this email directly, view it on GitHub <#869?email_source=notifications&email_token=AACHL6LOEV3JNBTHXIOPLGL45YDQDA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINJZG4YTOOBUGQ2KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4597178444>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACHL6LMAMWX3XRW64D6N7L45YDQDAVCNFSM6AAAAACZWIR5VCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DKOJXGE3TQNBUGQ> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AACHL6OY5ZXFM4BE4JAOZCD45YDQDA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINJZG4YTOOBUGQ2KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/AACHL6PXRTFLCPA32WUYXND45YDQDA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINJZG4YTOOBUGQ2KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.***>

   😕React with 😕1Reacted by Ben Thomas
5. kliuchev commented on Sep 29, 2026

   

   kliuchev

   on Sep 29, 2026

   Last edited by kliuchev

   Contributor

   More actions

   Proposal: target 4.0.0 for the next release

   @adamgit, could you take a look at this release proposal? There is a concrete build issue behind the request: projects depending on the 3.0.0 tag can fail to build when SwiftPM resolves a newer CocoaLumberjack version. That tag's Package.swift uses .upToNextMajor(from: "3.7.0"), which allows 3.10.0; CocoaLumberjack 3.10.0 requires iOS/tvOS 15, macOS 12, and Swift tools 6.4. Those requirements exceed the platform minimums declared by SVGKit 3.0.0 and can also exceed consumers' toolchain support.

   My merged fix in #879 caps the dependency at 3.9.1, but it is only available on 3.x; consumers staying on the 3.0.0 release do not receive it. This means affected projects need a dependency override or a switch to a commit/branch to build. A new tagged release containing the fix would provide a versioned upgrade path. Projects already resolving a compatible CocoaLumberjack version are not necessarily affected.

   Could the next release from 3.x target 4.0.0? Comparing 3.0.0 with the current head (6002a0f, including #879) shows compatibility changes that warrant a major version under SemVer:

   • Minimum OS versions increased: SwiftPM now requires iOS/tvOS 13 instead of 9 (Fixes #724 - SVGKitSwift SPM build issue (when archiving only) #726). The podspec raises iOS from 5 to 11, tvOS from 9 to 11, and macOS from 10.9 to 11 (#790 Xcode 14.3 Cocapods fix #792).
   • A public method was replaced: SVGLength's pixelsValueWithGradientDimension: became pixelsValueWithGradientDimension:treatAsPercentage: without retaining the original selector (Fixed a crash, a gradient render issue and an parsing assert #786). Existing callers need to migrate.
   • Swift source compatibility changed: explicit nullable annotations on parser results and properties can require optional handling in existing Swift code (fix: add nullability annotations to suppress 25 Clang warnings #874).
   • The minimum Swift tools version increased from 5.1 to 5.3 (Add PrivacyInfo.xcprivacy to Package.swift #825).

   The CocoaLumberjack constraint in #879 also needs a migration note: 3.7.0...3.9.1 can conflict with another dependency requiring a newer version. The podspec currently says 3.1.1, so its version should be aligned with the eventual release tag.

   Building on the release requirements above, a concrete scope would be to validate a fixed candidate across the supported platforms and installation methods, particularly logging and header/module imports; prepare release notes with migration guidance and contributor credits; then align the version metadata and publish the tag/release, coordinating CocoaPods publication with an authorized maintainer.

   This is a versioning proposal based on the source changes, not a claim that the current head has passed release validation. A 4.0.0 release would let consumers explicitly opt into these compatibility changes.

   ❤️React with ❤️3Reacted by Ben Thomas, Mickey Lee and Arturo Peña