Dears,
in the release note of the last ortools version I see that it is required:
Dependency updates
Abseil-cpp b832dce updated to c51510d (LTS 20200225.2).
What should I have to do to use it? I'm working in on Windows in python with a venv.
Sorry for the trivial question but it is not clear to me how to update it.
Thanks!
Related
I'm currently ugrading all my projects that use Schemacrawler. The last version I used was 15.06.01 and I'm upgrading to 16.9.4.
A lot of changes were done, I'm looking for the object that replace LintedCatalog.java.
The aim is to get the list of lints detected during a db analaysis.
The project I'm currently working on is : https://github.com/adriens/schemacrawler-additional-command-lints-as-csv.git, if you want to have a look.
Thanks in advance
Michèle,
Instead of code like createLintedCatalog, you could use a lint collector.
Sualeh, SchemaCrawler
I'm upgrading cucumber-js library in my project from v 1.3.2 to 3.0.3.
For now most things work as expected, but I found out that while I'm trying to run a single test scenario old way:
./node_modules/protractor/bin/protractor ./tmp/config/devDirectConnect.js --specs ./features/redirects.feature:20
the whole feature file runs.
Do you know what is a reason and maybe the solution?
Rgs
The syntax has changed since 1.x, and my answer to this question should also answer this one, as I show the syntactic changes needed to upgrade to 2.x or 3.x in the examples that I give there.
If there are any other syntactical errors, update your question and post a comment below to notify me, and I'll update my answer.
Fix for the issue has been released in cucumber-js 3.1.0:
https://github.com/cucumber/cucumber-js/blob/master/CHANGELOG.md#310-2017-10-25
I found a similar issue but couldn't understand any action to take. I have two open-source scala libraries - I published the second one just yesterday. Everything looks good on the Bintray repo, but only one version makes it to jCenter.
https://dl.bintray.com/ticofab/maven/io/ticofab/ :
aws-request-signer_2.10/
aws-request-signer_2.11/
aws-request-signer_2.12/ <-- latest scala version, missing later
reactive-kraken_2.11/
reactive-kraken_2.12/ <-- latest scala version, missing later
http://jcenter.bintray.com/io/ticofab/ :
aws-request-signer_2.11/
reactive-kraken_2.11/
Is there a way I can solve this? Thanks.
Thank you for your submitting this issue.
We have managed to resolve the issue you were experiencing. The issue occurred due to a bad link to JCenter.
Usually in order to add packages to JCenter, we add only packages under 'groupID/groupID/artifactID'. Since Scala packages are different and they contain versions of their own we needed to change the link to groupID only without artifactID (groupID/groupID. i.e /io/ticofab).
This means that all artifactIDs (reactive-kraken_2.11, reactive-kraken_2.12, aws-request-signer_2.10, aws-request-signer_2.11, aws-request-signer_2.12) are now approved and synced to JCenter.
We hope this clarifies. Please let us know if you encounter any other issues.
Best Regards,
Yonatan Brand
JFrog Support
I am wondering how can I ensure that my bower version configuration will be workable in the future?
E.g. I have already touched multiple projects, which either tell to use
">=1.0.0"
"~1.0.0"
Afaik the
">=" tells that all versions above 1.0.0 are fine
"~" tells all versions/minor updates on 1.0.x are fine
To be more specific:
"dependencies": {
"angular": ">=1.3.0",
"bootstrap": ">=3.2.0",
"jquery": "~2.1.0",
}
Of the day of writing this code following version configuration was included:
angular: 1.3.1
bootstrap: 3.2.0
jquery: 2.1.0
today you will get included:
angular: 1.4.0
bootstrap: 3.3.4
jquery: 2.1.4
From the point of the developers integration of the lib this features are fine on the beginning of the development. You have not to mess around with the painful dependency management of the libs and versions. But as soon as it gets tested the version should be fixed to defined versions.
I have already touched multiple projects which got broken after a very short period of 3 months, since the libs got updated to different versions, which either are incompatible to each other or some features got broken. So either the build was not working any more or even more bad, issues arise on client side.
What is the best practise to get rid of such version issues on the long term projects?
At the moment there is none, if your only option is bower. A lockfile a la composer or a shrinkwrap mechanism a la npm is in the works however it seems to have stalled as there are currently not enough contributors/maintainers to test the feature and maintain it in the long run.
UPDATE:
Since we now have yarn you can opt to use that, which uses a lockfile mechanism as the default behaviour. The only caveat is that it uses the npm registry which means that either some packages haven't been registered there yet, or have been namespaced like Google's Polymer which you might have to watch out for.
My get-t-go method is using exact versions,
don't let your dependency tool decide what version is best for you because they (and other people) are usually wrong.
What I mean by that is, and I have seen this plenty enough on bower. That one day you get version A.B.C and the next day you might get A.D.F and A.D.F conflicts with some other dependency you have. This can introduce all sort's of problems.
Best is to do handle all your upgrades yourself and test this yourself.
I have yet to see a project where UI and javascript testing was automated in such a way that this was done reliably.
I just published a package to nuget but realize I forgot to include a css file. My versioning is tied to the library I'm packaging (which I don't own) so I can't really increment it.
How do I force a re-push or what's the recommended thing to do in this scenario?
Found out an answer to my own question.
There is apparently no limit on how many version places there are so you can simple append yet another version place.
So for example if the package you're packaging is 0.0.1 you can upload another one 0.0.1.1