Actually I wanted to release this as version 1.5.4, but frankly I got lazy trying to separate new features from bug fixes. So let’s call this 1.6.0 instead.
Last update before WWDC. This is a maintenance release fixing some pressing issues, some of which were causing crashing.
Today we are releasing the 1.5 version of our rich text components. This marks the second unified release where several parts of our rich text eco system are maturing in lock-step.
For the most part these improvements and enhancements were funded from exceptional sales of DTRichTextEditor as well as several sponsors who stepped forward to allow me to finally get support for lists implemented.
From what I can tell the clients who licensed the editor are way more willing to contribute funds to something they have already paid for, than for enhancing the – otherwise free with attribution – DTCoreText.
Beginning with version 1.4 we will advance the version tags on DTCoreText and DTRichTextEditor in sync. DTCoreText is in charge of HTML parsing, display and HTML generation inside the editor component and thus all the changes done there are indirectly benefitting editor users as well.
I’ve begun to aggregate issues on both GitHub and our own private GitLab instance via milestones. These are the grouping unit collecting issues so that you can tell from which version onward these fixes or enhancements are available. Each milestone will become a tag, once it is completed and will represent a stable version.
Funny Story: right after I published my findings on how to work CocoaPods I received a couple of pull requests. Should it be actually be the case that fellow developers are beginning to take notice of DTCoreText?
I admit, that for the first few tags/versions of DTCoreText I didn’t take CocoaPods seriously. But since I got down how to work with sub-modules and sub-specs I find that it gives me a great deal of pleasure to keep my specs current.
Other people take off the Christmas holidays to have fun. I delight in using the time away from normal programming work to work on DTCoreText.
There are many wide-reaching changes to warrant an increase in version number on the second digit. I need to sum them up in this location because you might have projects that rely on DTCoreText for displaying attributed strings.
I reported a while ago that I was forced to tag the current state of the DTCoreText master repository as 1.0.0. The reason for this was that CocoaPods was starting to gain lots of momentum and several people wanted to use DTCoreText via a podspec.
You can have podspecs point to the master branch as well, but then you never really know what you get. This can possibly cause many headaches especially in larger projects where you cannot track the state of each individual sub-project.
Therefore it is generally recommended – if not required – to make use of tags in GitHub.