Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Implement podfile.lock logic #191

Closed
sergeyzenchenko opened this Issue Mar 26, 2012 · 8 comments

Comments

Projects
None yet
3 participants

I found an issue. I have a Podfile with

dependency "AFNetworking", "0.5.1"

if I will change version to latest "0.9.1" and run "pod install" it will say what "Using AFNetworking (0.9.1)", but it's not true!.
In file system I still have version 0.5.1 and it will works only if I will remove folder with pods and run "pod install" again. Same with changing version from newest to older.

Owner

alloy commented Mar 26, 2012

Yup, we have been cheating all this time and kept it real simple :)

There is already a ticket for this, #131, but it’s implicit, so I’ll leave this open.

I dont want to wait to 0.7 version :) I've forked it and going to fix it. Do you have any useful information about this issue what can help me?

Owner

alloy commented Mar 26, 2012

Sweet!

You will have to use YAML to read the Podsfile.lock file and check the currently installed version, and then update the library if the version in the Podfile file is higher.

You can use the Pod::Version class to compare the versions.

I think we should update if version in Podfile is different from lock file, not just higher. User can set lower version for example.

Owner

alloy commented Mar 27, 2012

Yeah indeed.

Owner

fabiopelosin commented Jun 5, 2012

Moving this to 0.6.1 as everybody is expecting it to work.

Owner

alloy commented Jun 5, 2012

I’ve just added a wiki page about how we should imo proceed with releases in the future, this also means we need to evaluate our way of dealing with milestones. Since this is a feature addition it would bump the minor version, but that does not mean it has to be far in the future.

Owner

fabiopelosin commented Jun 7, 2012

I've updated the title title of the issue.

@fabiopelosin fabiopelosin added a commit that referenced this issue Aug 8, 2012

@fabiopelosin fabiopelosin Introduced Pod `update`, `outdated`.
See #131, #191.

- The installer is initialized with a resolver. The resolver is responsible of
  indicating which specs must be installed/reinstalled.
- It was introduced a slight change in the format of the Podfile.lock.
- The specification set was simplified to receive and handle Pod::Dependency
  instead of Pod::Specification. With this change it also appears to be more
  robust.

A this stage it appears to be working. However the support, for external and
head dependencies is weak.
34a6853

@jzapater jzapater pushed a commit to jzapater/CocoaPods that referenced this issue Sep 17, 2013

@waterlou waterlou Merge pull request #191 from waterlou/master
fix vfrReader duplicated source file
d994ffc

@fabiopelosin fabiopelosin added a commit that referenced this issue Oct 25, 2014

@fabiopelosin fabiopelosin Introduced Pod `update`, `outdated`.
See #131, #191.

- The installer is initialized with a resolver. The resolver is responsible of
  indicating which specs must be installed/reinstalled.
- It was introduced a slight change in the format of the Podfile.lock.
- The specification set was simplified to receive and handle Pod::Dependency
  instead of Pod::Specification. With this change it also appears to be more
  robust.

A this stage it appears to be working. However the support, for external and
head dependencies is weak.
21b42a0
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment