Several latest ML Kit stable packages like:
com.google.mlkit.image-labeling-common-17.1.0
com.google.mlkit.object-detection-common-17.1.0
and google play service artifacts like:
com.google.android.gms.play-services-mlkit-text-recognition-16.3.0
com.google.android.gms.play-services-mlkit-barcode-scanning-16.2.0
com.google.android.gms.play-services-mlkit-face-detection-16.2.0
depend on prerelease/preview package com.google.android.odml.image-1.0.0-beta1
Note: I did not investigate transitive dependencies.
When can release of com.google.android.odml.image-1.0.0 be expected?
We are actively working on it, but don't have an ETA yet.
Related
We have a React App which uses some components written by us and published to our internal npm repository. Our code is maintained in Bitbucket Data Center, the build is done with Bamboo and the npm repository is hosted in JFrog Artifactory. We work with feature branches and pull requests for developing new features.
It happens often that a new feature in the app, requires a change in the component. In this case, each repository (the App and the component) will have its own feature branch and pull request. Many times the component interface changes, so that the App needs the pull request version of the component and not the mainline one to build and to be tested.
The build is done exclusively by the build server, so that the bundled javascript files are not committed to git.
Let's say the component has version 1.0.0. A new feature in the App needs a change in the component. In this case, the component version will incremented to 1.0.1. We don't want to publish it to Artifactory, until version 1.0.1 is tested, but at the same time, the build of the new App version needs the changes from version 1.0.1.
Our current solution is to change the package version of the component during the build of feature branches to something like 0.<Ticket #>.<Build #>. This 0.x.x version will be published to Artifactory so that the App feature branch can use it to compile.
We use 0.x.x so that the version is never bigger than the current released version. Once the component is merged to the main branch, it will compile with the right version (1.0.1) and will be published to Artifactory again.
I find this solution cumbersome, it requires some funny build scripts, making sure that the branch name always follows some convention and teaching developers about it.
I wonder if there is a better way for managing pull requests and feature branches using npm, without having to manipulate the package.json during build time, depending if it is a feature branch or the main branch.
Sounds like you are using artifactory like a secondary version / staging for the npm package, just use npm?
I am not in devops, but have worked on a few packages, testing a package that has not been released does not sound like testing the package - what about using a beta tag npm publish --tag beta, pulling that into your app npm i package#beta then testing your application in a staging environment?
As i expect you know if you apply a tag then the tag would need to be specified to be pulled into a repo so you can use it to deter users from using that version of the package - an i believe you can delete versions later if you are dead set on not having it public.
Here is a medium article which may be helpful?
After doing a fresh install of the VC platform and VC storefront from source code, I chose to install the sample data. I am getting an error in the Smart Caching Module, which states Module platform version 2.13.28 is incompatible with current 2.13.26;
In my VC Platform solution, I can see the version is in fact set to 2.13.26 in my common assembly file - and in my Smart Caching Module the target version is in fact set to 2.13.28.
How can I roll back the Smart Caching Module to target the 2.13.26 version? Or is it easier to upgrade the platform to version 2.13.28?
Thanks
Yes, the easiest way to update your VC platform to the latest version. https://github.com/VirtoCommerce/vc-platform/releases
I've found chronicle-queue version on maven central is quite old: 4.5.27, while 4.6.23 is most recent released on github. Does it mean 4.5.27 is a kind of "prod-ready", while all 4.5.27+ are experimental? Or you use other repositories for distribution?
The 4.5.27 version is stable and available to all users.
The 4.6.x version is being developed and available to supported clients. We expect to make a public release of this version this month.
I noticed on the rules_closure repository (used by tensorflow when building it with //tensorflow/tools/pip_package:build_pip_package) that there are rules to build some dependencies like nodejs and protoc through the filegroup_external interface.
Why is the reason for not building it from scratch like other dependencies?
I ask because this approach compromises portability, as it needs to list the binaries for each platform that tries to build tensorflow (and it is even worse when there is no binary-ready for your platform).
This build configuration works deterministically, out of the box, with no systems dependencies, on recent Linux/Mac/Windows systems with Intel CPUs, and incurs no additional build latency. Our goal has been to optimize for the best build experience, for what's in our support matrix. I agree with you that an escape hatch should exist for other systems. Feel free to open an issue with the rules_closure project and CC: #jart so we can discuss more how to solve that.
We are big users of NuGet, we've got 25-30 packages which we make available on a network share.
We'd like to be able to test new packages before they're built and released in the consuming applications. Ideally, this could be done using something similar to Maven's snapshot and having a specific development package (e.g. snapshot functionality).
Has anyone else come up with a, ideally reasonably non-hacky, way of doing it?
Our favoured method is to generate the package assemblies and then manually overwrite the assemblies in the packages/ directory, i.e. to replace the actual project references, but that doesn't seem particularly clean.
Update:
We use a CI build server which creates builds on every commit and has a specific manually triggered NuGet build which works off specifically tagged versions of the codebase. We don't want to create a NuGet build off every commit, but we would like to be able to test a likely candidate in the wild before we trigger the manual NuGet package build.
I ended up writing a unit / integration testing framework to solve a simular problem. Basically, I needed to verity the content of the package, the versions and info, what would happen when I installed and uninstalled the package, what versions were the assemblies in the lib, what bits the assemblies were built as (x86 or x64) and so on - and I needed it all to run without Visual Studio installed and on my build machine (headless) as a quality gate.
Standing on the shoulders of giants like: Pester, PETools, and SharpDevelop's package management module I put together - nuget-test
Clone the project into your package directory (where your .nuspec file and package files are). If for whatever reason you want to keep the nuget-test project as a "git" repo then simple remove "remove-item nuget-test/.git -Recurse -Force" from the command below.
git clone https://github.com/nickfloyd/nuget-test.git; remove-item nuget-test/.git -Recurse -Force
Run Setup.ps1 in the root of the nuget-test directory in an x86 instance of PowerShell.
PS> .\setup.ps1
Write tests and place them in the nuget-test/test directory using the Pester syntax.
Run the tests.
PS> Invoke-Pester
Project page: nuget-test
On github: https://github.com/nickfloyd/nuget-test
I hope this helps you get closer to what you're trying to get done.
If you're using NuGet packages to distribute your libraries, you should not limit to only testing the libraries. You should test the packages themselves as well (if your binaries are OK but incorrectly installed, consumers still have issues). The whole point is to improve this experience.
One way could be to have an additional CI or QA repository. The one you currently have is actually your "production" repository containing consumable releases, considered finished high-quality products.
Going further, you could have a logical package promotion flow (based on Continuous Integration or even using a Continuous Delivery approach), where:
- each check-in produces a package on your CI repository
- testers pick up a CI package for QA and if found OK promote it to either a QA feed, or to the Production feed (whatever you prefer, depends on the quality of your testing and how well it is automated)
There are various ways of implementing this scenario, using simple network shares, internal NuGet.Server or Gallery implementations, or simply use http://myget.org to give it a try with minimal cost and zero effort.
Hope that helps!
Cheers,
Xavier