Print the changes introduced when upgrading a Pod #944

Closed
MaxGabriel opened this Issue Apr 6, 2013 · 12 comments

Projects

None yet

9 participants

@MaxGabriel
Contributor

Cocoapods has been really revolutionary in iOS with regards to introducing semantic versioning and (for me atleast) consistently updating dependencies.

Furthering ease of integration with open-source projects, it would be useful if Cocoapods printed the changes introduced when upgrading a Cocoapod. Projects like AFNetworking, SSToolKit and Kiwi already keep changelogs, but their format and filenames are inconsistent. Cocoapods would probably have to ask changelogs to follow some standard format.

Printing changes would help with the Dependency Version workflow by making major version upgrades explicit about what breaking changes were made, and generally keeping users informed of what bugs or improvements were made to their dependencies.

@alloy
Member
alloy commented Apr 7, 2013

I like the general idea. 👍

However, I don’t have a firm understanding of the scope of the changes that lib authors would have to apply to their changelog format. Why would that have to be the case at all?

Is this feature something you would like to work on?

@fabiopelosin
Member

👍

@supermarin
Member

👍

@Zyphrax
Zyphrax commented Apr 9, 2013

👍

Perhaps CocoaPods could look for files named "Changelog" (with or without extension), with the option of defining a custom filename in the Pod's podspec.

@fabiopelosin
Member

I agree that CocoaPods would look for files named changelog{,.*} but I don't see a need for a DSL attribute.

It is still unclear to me how CocoaPods will split the changelog by version. The only possible solution that I see is to look for the headers matching the versions.

We could use the same implementation for issue #853.

@lukabernardi

👍

IMHO also the command pod outdated can benefit from the presence of changelog. Imagine if other than show you which pods are outdated it will show you a change log of them. Maybe this is even more useful than showing it post install.

@alloy
Member
alloy commented Apr 23, 2013

After thinking about it some more, I don’t think checking for a changelog file is a good idea. Many people have their own format, so this is guaranteed to not going to work for some.

An alternative would be to just have a change_log attribute where the entries for that version can be defined and possibly the spec author can use this to dynamically load the changelog from an existing changelog file, but I’m on the fence on wether or not that’s usable.

@orta
Member
orta commented Jun 5, 2013

Related: I was thinking of eventually building something automated like this for CocoaDocs so you can do version diffs.

If someone else does something like this that'd be mega good ( that kinda thing isn't my forte. ) My plan of attack was to use @kattrali 's ruby app for parsing Docsets and then somehow looking at the diffs between the two versions.

@fabiopelosin
Member

@orta 👍 Interesting stuff!

@kattrali
kattrali commented Jun 5, 2013

@orta I may be able to help with the automating part, or at least generating a diff-able summary from a docset.

@CocoaPodsBot

@joelparsons closed with reason "It seems to me like the feature idea was deemed to be not workable"

@MaxGabriel
Contributor

Yeah agree thanks for closing @joelparsons

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment