I recently downloaded a new symfony2 package for websockets and included it into my composer file,
when I called
php composer.phar update
It automatically updated my Symfony version and I was wondering if updating Symfony2 will break the website in the long run, since part of my source code could become obsolete (deprecated)
Yes, if composer downloads a version of a dependency that's not backward compatible with the version that you used to develop your website, things might/will break.
However, you can limit the possibility by defining good rules in your composer.json.
First of all, it might be good to learn about semantic versioning if you haven't heard of it already. Many projects are following the rules of semantic versioning, which basically state that if a project/library has changed in a way that is not compatible with earlier versions, it's main version number should be incremented. For instance, if 1.5.x had a certain feature, and an update is made where that feature is changed or no longer available, the new version number should be 2.0.x instead of 1.6.x.
Knowing this, you can use Composer's tilde operator (~) to define useful version constraints. For instance, to add the dependency to symfony's files, you can add the following requirement to your composer.json:
"symfony/symfony": "~2.3"
which is equivalent to:
"symfony/symfony": ">=2.3,<3.0"
or, in plain English: 'give me a version of symfony/symfony, at least version 2.3 or higher, but lower than 3.0'. If Symfony follows semantic versioning correctly, no backward incompatible changes should be made in any 2.x versions (and, if any backward incompatible changes are made, they should come with version 3.0), so you should be fine.
This actually depends on how your composer.json is configured. If your dependencies use SemVer, and you are referencing them in your composer.json only allowing patch version changes (like "package-name": "1.1.x"), then everything should usually be fine.
Also, note that you can pass a package name as a parameter to the composer update command, e.g. php composer.phar update <vendor/dependency-name>. This will tell Composer to only check if there are updates available to <dependency-name> package, given your current composer.json version constraints.
If you want to check that nothing is broken after an update and you're not keeping the update scope as narrow as I specified, then something could break. The best way to detect and avoid this is by testing.
You should read about composer.lock file. This will make sure that Composer will not update any version of the repository and only what you specify in the lock file
Related
I want to change one of my library to the latest version. where to find the version of the dependency in play.
In general, you can see a list of Play's direct dependencies by checking the project/Dependencies.scala file in the source code for that version of Play. For version 2.4.3, that file is here: https://github.com/playframework/playframework/blob/2.4.3/framework/project/Dependencies.scala
In the specific case of Jackson, the group ID and module structure changed between Jackson 1.x and 2.x. Play 2.4.3 is using Jackson 2.5.4. If your project depends on Jackson 1.8.5, this dependency isn't coming from Play, but from some other source.
You can use the sbt-dependency-graph plugin to view the full tree of transitive dependencies and see where it is introduced.
To update to a newer version, you can add a direct dependency to your build.sbt with the desired version:
libraryDependencies += "org.codehaus.jackson" % "jackson-mapper-asl" % "1.9.13"
This will override the version requested by other libraries; by default, sbt will use the greatest version requested.
However, there are a few things to keep in mind:
Jackson is composed of several sub-modules. If you are using several of these in the same project, including transitively, it's a good idea to use the same version of all of them. This might require adding additional dependencies to your project to keep them all in sync.
When upgrading dependencies in your application that are also used by other libraries it depends on, you'll need to consider backward compatibility. Jackson is not always fully backward compatible between minor versions, so if you update to a newer version of Jackson than what your libraries were designed to use, you might encounter problems at runtime.
Using both Jackson 1.x and 2.x in the same project is possible, since they have different group IDs and Java package names, but it may be confusing and error prone. If you can, it would be better to standardise on the Jackson version that is used by the Play Framework version you choose.
Using ASP.NET Core 1.0, is it best practice to check in the project.lock.json file into source control?
Short answer: No, project.lock.file should not be checked into source control - you should configure the version control system to ignore it (i.e. add it to .gitignore if you're using git).
Long answer: The project.lock.json contains a snapshot of project's whole dependency tree - not just packages listed in "dependencies" sections, but also all resolved dependencies of those dependencies, and so on. But it is not like ruby's Gemfile.lock. Unlike Gemfile.lock, project.lock.json doesn't tell dotnet restore which exact versions of packages should be restored - it simply gets overwritten. As such, it should be treated like a cache file and never be checked into source control.
If you check it into version control, then most probably on other machine:
dotnet will think that all packages are restored, but in fact some packages might be missing and the build will fail, without hinting the developer to run dotnet restore
project.lock.json will be overwritten during dotnet restore and in most cases will be different than the version stored in source control. So it will be modified in almost every commit
project.lock.json will cause conflicts during merge
Actually you do want to commit your project.lock.json in git sometimes.
Checking your project json
For the exact reasons that, it shows you the dependencies you have used. Say:
Me as a developer works on an application, i hate every time updating packages so i add a package dependency to nuget package X = 1.*
I restore package i get version 1.2.4
The package maker just made a very stupid mistake, he broke something while just trying to make a fix and release 1.2.5
Person 2 checks out (or even worse release build kicks in).
Person 2 restores and gets version 1.2.5
Person 2 runs your application and find the application is broken.
Person 2 starts debugging and thinks there must be a bug in the software.
At this step 7 Person 2 could have seen in git that his lock file was changed and a newer version of a library has been downloaded, Which has not been tested by any of the other developers!
Downsides
Downsides of checking in this file is you might get allot of merge conflicts on continues updates of packages.
Alternative solution
Use only hard version dependencies (this is quite hard though for nuget). And only manually update to newer version once in a while.
Downsides
This doesn't work if you build a library for other people to use, since you pin them to a certain version of your dependencies.
Dependencies of dependencies still get resolved automatically so if you don't specify them yourself you can't guarantee there version on dotnet restore
Conclusion
If you want to avoid 'Works on my machine' quotes and the hell of constantly manually updating to newer version: Checking the project.lock.json.
And also build a CI/Release build check to test if this file wasn't changed compared to git, before you release (If your software is very critical)!
If this is not a problem and also automatically updating (to a potentially broken package) is not a big problem, you might not want to commit your project.lock.json.
No, it is just a lock file, really you should never check it in when a lock file exists (except if the program who locked it wants to check it into source control, in that case, exclude your lock file!).
If I understand it correctly, the SymfonyRequirements.php file (which lives under /app or /var depending on Symfony version) is handled by Composer. I therefore suppose it should be not be tracked by any version control system. However, I see it is excluded from Symfony Standard Edition's .gitignore file:
/var/*
[...]
!var/SymfonyRequirements.php
Edit
Symfony core developer #Stof says in a Github issue:
given that one of the checks is whether you installed vendors, it must
be there before installing them (even though we have an automatic
update of the requirements so that you check the uptodate ones next
time).
This is not very clear to me. Can anybody give any more details about this file and explain why it should or should not be tracked by a VCS?
This file is used by Symfony Check CLI Script to check for minimum requirements of configuring & running a Symfony App. It's a Common Post-Deployment Task.
It checks for current PHP Version/Configurations(php.ini settings) and required PHP Extensions. For example it checks for current setting of date.timezone.
What #stof is trying to say is that you should be able to run the checks even before installing dependencies using composer install. It even checks for dependencies installation itself: checks for existence of vendor/composer directory.
It gives you a good & enough insight about whether the Symfony App has what it needs to be run based on Current PHP configuration.
Note that by adding this file to VCS, you should know there may be changes to this file after updating dependencies later using composer update. So you should remember to commit this file too!.
Please Note that these checks also provide some recommendations(not requirements) to be set. For Example check this recommendation out:
When using the logout handler from the Symfony Security Component, you should have at least PHP 5.4.11 due to PHP bug #63379 (as a workaround, you can also set invalidate_session to false in the security logout handler configuration)
Some other Projects using Symfony also implement their own checks by extending this file, For example checkout Oro Platforms Requirements Check.
The files is used in the check CLI tool that use this files for control the minimal Requirements for Running Symfony. You can find more info in the doc.
Usually is take into account in a version control system, as you can see in the symfony-standard distribution project on github:
https://github.com/symfony/symfony-standard
(of course you can add the files in your custom .gitignore files)
For more precision, this file is used in the command php bin/symfony_requirements in symfony3 and php app/check.php for older, that checks your php/symfony requirements.
See this question Should the changes of SymfonyRequirements.php be included in version control? and the documentation.
I am using Spring Source Tool Suite 2.8.1 to implement Spring applications.
I frequently get build errors because references are lost for no apparent reason. In Right-click project in Package Explorer->Properties->Java Build Path->Order and Export, I find projects sometimes are deselected. And often packages are gone in Right-click project in Package Explorer->Properties->Java Build Path->Deployment Assembly.
Having to reset these settings frequently is frustrating. Is there some way I can work around these problems?
I have tried to update STS to the latest version, but the upgrade process fails with incomprehensible error messages. I want to avoid a clean install because setting up the environment again would probably be a nightmare.
Now that I know this is a maven project and you are adding references yourself, this is making sense to me. STS 2.8.x was the last STS to ship with the legacy m2e (maven plugin for Eclipse). It did not recognize build path entries added manually (it likes to have complete control over the classpath). So, what is likely happening is that you are adding these classpath entries and then an update project operation gets kicked off automatically. This will have the effect of removing all of your extra classpath entries.
You are best off doing the following:
Updgrading STS
Or just upgrading your m2e component (you will have to first uninstall the old m2e, but this should be taken care of automatically from the discovery update page).
Or, just accept the fact that you can't manually change your classpath with the legacy m2e.
I have a private bundle that I import in the vendor.
Now, I'm working in my project and want to edit some code in the vendor bundle.
Now I've done that and want to commit to code, so I go the dir of that bundle and say: "git commit -a" so I give a message, save and now I have a commit. Oke, "git push" and give the response "Everything is up-to-date"... So I can't push that but I can commit??
Is this not a way to commit? Should I just clone the repo and work there?
You should never edit the vendor code directly - this is the whole point of dependency management.
Composer basically works by looking at your composer.json file, and fetching the repositories and versions you specify. If you need to make changes to one of your dependencies, you should make the change in the original repository, push the changes up to GitHub (or wherever you're hosting the code) and run composer update.
When Composer installs a vendor, it checks out a particular commit, so you are not on a branch. You need to checkout the master branch — or whichever you're using — and commit to it and push it.
Its a long time ago that I asked this question. Mean while I got the answer but never updated my stackoverflow question, sorry for that!
The answer on my own question is to get the dependency with composer --prefer-source.
https://getcomposer.org/doc/03-cli.md#install
--prefer-source: There are two ways of downloading a package: source and dist. For stable versions composer will use the dist by default. The source is a version control repository. If --prefer-source is enabled, composer will install from source if there is one. This is useful if you want to make a bugfix to a project and get a local git clone of the dependency directly.