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.
Related
maybe someone has a good idea for the following scenario:
I have
prerelease dev packages, like that: packagename.1.2.0.1000-dev.nupkg
and
release packages, like packagename.1.2.0.1.nupkg
My idea was: starting at a higher number range for the dev packages would always allow getting the dev packages for developers if they enable the Pre-Release option at the nuget update step. This works fine.
Then later on I would like to update the project to the latest release version. But it seems there is no option to update to the latest release version that has a lower version number than the dev/pre-release package? Also the -Safe option doesn't seem to work here.
I can't keep the build numbers in sync also since these are different builds. If I have it the other way around, so higher build numbers for the release versions, it would never update to the latest dev packages if I do a normal nuget update, even including the pre-release packages...
Any idea here?
Thanks a lot!
Any package that is publicly available is a "release package" in technical/English terms. But the software industry has bastardized the language. So lets talk about stable (no prererelease tag) and unstable releases (prerelease tag).
The publisher history should be something like this:
1.0.0 // First **stable release**
1.0.1-alpha // First **unstable release** Candidate bug fix.
1.0.1-beta // 1.0.1-alpha with a tweak to the code.
1.0.1 // Second **stable release**
If the publisher follows that pattern, then end-user clients can safely pull stable release bug fixes while developers can also pull unstable prereleases at their discretion.
You can also have something like:
1.0.0 // First **stable release**
1.0.1-a.dev.1 // Next CI build after 1.0.0
1.0.1-a.dev.2 // Etc...
1.0.1-alpha // Relabeled 1.0.1-a.dev.2.
1.0.1-beta // Relabeled 1.0.1-alpha, wider audience than -alpha.
1.0.1 // Second **stable release**
It's a good practice to have separate feeds for internal dev/test, public prerelease and public stable releases.
I think I am missing something, but I want to add library from github to Android, I don't see anywhere on the Github page the latest built version of the library so I can include it in my gradle file. I have to go to maven or jetpack manually and search for it. Is there a shortcut? Am I missing something?
Thanks
There is a Lint check which allow Android Studio to query the latest versions available.
First you will have to activate this Lint Check
Go to Settings, then Editor > Inspections and search for Newer Library Version Available and check it.
Then run a code Analyze with Analyze > Run Inspection by Name... and type newer and select Newer Library Version Available
Run the inspection on the wanted scope (module only, full project, etc...)
Then you will see which library has a new version available.
PS
As stated by the Lint description of this feature, you should not let this check activated because it may slow your code analysis (query the repositories can take time)
You can use the + annotation to get a dynamic version. It can be use for the major, minor and patch part of the version. Ex :
// Major
compile group: 'org.mockito', name: 'mockito-core', version: '+'
// Minor
compile group: 'org.mockito', name: 'mockito-core', version: '2.+'
// Patch
compile group: 'org.mockito', name: 'mockito-core', version: '2.18.+'
But it's not a good practice to use such a dependency resolution.
Dependencies can unexpectedly introduce behavior changes to your app. Read your changelogs carefully!
The same source built on two different machines can differ. How many times have you said "but it works on my machine?"
Similarly, builds built on the same machine but at different times can differ. I've wasted so much time on builds that worked one minute
then broke the next.
Past builds cannot be reproduced perfectly. This makes it difficult to revert safely.
There are security implications if a bad actor introduces a malicious version of a dependency.
I'm currently in the middle of upgrading our API from v0.12 of Sails to v1. Not the easiest task, but will be worth it.
The current problem I'm having, is converting our old "ModelName.query" calls to the new style, which is supposedly "sails.getDatastore". Great, fine.
Except, that when trying to do this in config/bootstrap.js, I constantly get the error "sails.getDatastore is not a function".
Yes, I am using the default sails-hook-orm, the .sailsrc has it turned on explicitly; and yes, I have globals turned on.
Is the problem that the function isn't registered until after bootstrap? Because that is not an option for us; bootstrap is validating our database schema before lift (custom code, using native queries), so our production servers fail to deploy if we missed a database update. It eliminates a ton of human error.
Thanks for taking the 1.0 plunge!
I'm not sure what you mean by the "default" sails-hook-orm -- that hook is installed directly as a dependency on each Sails 1.0 project -- but I can almost guarantee that the version you're using is not correct. I would do:
npm cache clean
npm install sails-hook-orm#beta
in your project to make sure you get the latest (currently v2.0.0-21). It adds getDatastore to the app object when it initializes.
I have flow integrated into a webpack / babel build using flow-babel-webpack-plugin and it works great. Webpack dev server compiles / serves assets in less than a second and if there are flow type errors it prints them out nicely. I'm very happy with that.
The problem begins when I turn on my IDE. In both VSCode and Atom, if I enable any kind of flow support, my webpack / babel build immediately begins to choke. It will take anywhere between 4 and 70 seconds to compile any change. Often it fails and gives multiple flow is still initializing notices and indicates it has tried to start the server over and over.
I suspect that both webpack and the IDE are trying to spin up separate flow servers at the same time and this is causing a conflict. Or they are using the same flow server and this is, for some reason, also a problem. I just can't figure out what to do about it. I have tried pointing at separate binaries with webpack using the global flow and the IDE using the one from node_modules. No dice.
It seems like this must be an extremely common use case - flow + a webpack watcher + any IDE whatsoever.
I'd like to have both my webpack build compile flow code and have my IDE show me syntax errors etc. So far that's been impossible
It looks like that plugin uses its own copy of Flow, from the flow-bin package:
index.js
package.json
If this version is out of sync with what your IDE is starting up, then they will fight -- starting up one version of Flow will kill any Flow server with a different version that is already running in that directory.
If you put flow-bin in your devDependencies (alongside this webpack plugin) and lock it to a specific version, and also set your IDE to use the Flow binary from flow-bin, then it looks like npm will just install the version you specify, and both the plugin and the IDE will be able to use the same Flow version.
Without knowing more specifics about your setup, it's hard to recommend a more concrete solution. You'll have to either make it so both your IDE and this webpack plugin are running the same version of Flow, or stop using either the IDE or the webpack plugin.
i'm having some issues getting modules to work on my app - I keep on getting told that the requested module cannot be found.
It is entirely possible that i'm not installing the modules correctly - so, for the purposes of this question:
Once i've downloaded the zip file from git hub using the green "download" button, what do i do to import the module into my project? Not how do i tell tiapp.xml to use the module - just what do i do to install it?
Can you please run through using the facebook module found at https://github.com/appcelerator-modules/ti.facebook
thanks!
Inside the zip file of the download you'll see there is a folder called modules. This is the same folder that is in your root of the project.
So, an iOS module should be installed in the /modules/iphone folder. Once added, you can add Facebook to your app like this:
<module platform="iphone">facebook</module>
If you want to specify a version you can do so like this:
<module platform="iphone" version="1.1.0>facebook</module>
note: I made up the version number
You can also add it through the tiapp editor in Appcelerator studio, although it doesn't always seem to find the module. This might be a bug in studio though, usually it works great.
HMMMM
Two main issues here, one directly relating, the other less so.
Issue 1
The link i gave to get the codebase from github is wrong - well, it gets the codebase, but not in a form that can be used as a module. It is, in fact, the uncompiled version.
Versions for download can be found here.
So that takes care of issue one, what about
Issue 2
The latest version for use is a bit broken. Seems someone (from the appcelerator team???) decided to make the latest 6.0.1 release have a minsdk of the (at this time) as-yet-unreleased version 6.0.0, and sets the apiversion to 3.
This breaks the current release of 5.5.1, so for anyone reading this prior to 6.0.0 for appcelerator, you will want to use this release version.