0.9.12 available at pypi
launchpad jumps to 0.10 after 0.9.10 with no mention of .11 or .12
github indicates 0.9.11
the official documentation does talk about but doesn't provide links for download for 0.9.12.
Graphite uses semantic versioning.
0.9.x is the "Current Stable Release" branch and 0.10.x is the "Active Development" branch (as indicated by the launchpad page). If you're looking for the most pain-free version you should work with the latest version on the stable release branch, currently 0.9.12, available from github and pypi.
Related
I need to get acquainted specifically with elm 0.16.XX because some project I am working on is using it, and long story short,e.g. the version cannot be changed. Also, as you guys know there is a significant change between 0.16 and later elm versions. I am doing an online video course that has the 0.16.XX version but when I install elm, it naturally installs the latest version. How can I install the older versions?
The info I see online says to just change in elm.json, the version numbers of dependencies you need, but the problem is that the names of the dependencies have also changed. e.g in a basic hello world project,
0.16.xx
"elm-lang/core": 5.1.1, "elm-lang/html": 2.0.0, "elm-lang/virtual dom": 2.0.4
as opposed to modern elm
"elm/core": 1.0.5, "elm/html": 1.0.0, "elm/virtual-dom": 1.0.3
So how do I go about installing older elm i.e 0.16.XX. Any help is appreciated.
In theory, you could download the source code zip and try to build from sources but I remember people having a lot of trouble with the particular Haskell dependencies.
If the app is an Html based app that used evancz/start-app you might have some luck by first upgrading to 0.17.1. Take a look at https://github.com/elm-lang/elm-platform/blob/master/upgrade-docs/0.17.md
You might be able to install 0.17.1 with npm i -D elm#0.17.1.
elm.json is available only to 0.19 and 0.19.1 projects. The versions before that used elm-package.json
You can download Elm 0.16 installers for Windows and Mac Elm from the official releases.
https://github.com/elm/compiler/releases/tag/0.16.0
But I have no idea if installing the dependencies still works.
So maybe you'll need to incrementally upgrade your code, see https://github.com/elm-lang/elm-platform/tree/master/upgrade-docs
If that is too complicated, maybe you can ask in the Elm slack if someone can upgrade the code for you? E.g. with a small freelancer contract?
I am planning to upgrade artifactory-pro from 4.14.2 to 5.7. Has anyone done this so far? We use npm, bower, debian, yum repositories. Any recommendation or insight is appreciated.
As I see it, the upgrade depends on two main factors:
Your installation type(ZIP/RPM/RPM OSS/Debian/Docker). Here you can find detailed instructions for each type:
ZIP installation
RPM installation
RPM OSS installation
Debian installation
Docker installation
In case you use an HA cluster, here are the instructions.
While no special operations are required except those are mentioned in the instructions - please pay attention to updates and other special instructions since there are specific instructions to upgrading from Artifactory 4.x to 5.4.x and above. As can be seen here (for example).
Like in any other upgrade process, make sure you have a full system backup (Artifactory configuration, metadata, and artifacts)
I would like to know how to get the latest version of Firebase. How would I select from latest, beta, or stable versions?
As of now, I believe the latest Firebase is version 3.5.1. I am not even sure.
Any help or suggestions is appreciated.
The latest Firebase releases, for all platforms, are listed in the release notes, which can be found here.
If you are using the NPM-distributed Firebase, you can run the following command to see the latest version:
npm view firebase version dist-tags
Which effects the following output:
version = '3.5.1'
dist-tags =
{ latest: '3.5.1',
'1.2.0-beta.1-0': '1.2.0-beta.1-0',
'1.2.0-beta.2': '1.2.0-beta.2',
'1.2.0-beta.3': '1.2.0-beta.3' }
Note that dist-tags includes the latest, stable release and some very old betas. As mentioned in the comments, the latest, stable release is the only Firebase release. If beta or next versions were to be released, they would typically be listed in the dist-tags.
It is rather tedious when trying to get dependencies of local Meteor packages up-to-date.
Currently, they are specified in package.js like and I have to check for latest version of each dependency used and update manually.
E.g.
api.use([
'alanning:roles#1.2.14',
'aldeed:simple-schema#1.5.3',
'aldeed:collection2#2.8.0',
'iron:router#1.0.12',
'useraccounts:iron-routing#1.12.4'
]);
Can meteor-tool do this or is there a better way to update packages' dependencies, especially useful when you have multiple local packages in a project.
There is no real value in bumping the dependency version in package.js, as I mentioned in my comment. It could lead to the counter effect and break version resolution.
The expectation is to mention the minimal compatible version (with the same major version number). When your local package is updated, its .versions file is updated as well, which may hint the build system which version of the dependency is the preferred one to use (the one that your package was built with).
The closest thing that I can give as an answer is this quote of David Greenspan* taken from the Meteor forums:
We have made some small improvements to meteor update over time, but
we don't have a way for a package to ask for one of its dependencies
to be upgraded more aggressively. meteor update with no arguments will
take patch updates to indirect dependencies, but not minor versions. I
recently improved the messages that meteor update prints, so in the
next release, it should tell you if an indirect dependency is not at
the latest version after it runs (rather than printing the very wrong
message "All packages are at their latest compatible versions").
If you bump the minor version of a package, I think the expectation at
the moment is that you will republish the packages that depend on it
if you want their users to get the new version (after running the
tests to make sure all is well).
So, when the author of a package you depend on releases a new:
patch version: no need for you to do anything. The new version should be used automatically.
minor version: check that everything works and release a new patch version, as to acknowledge the new version.
major version: things are expected to break. Make the required changes and release according to semver rules.
I would not count on things behaving as they do right now, as the packaging system undergoes pretty significant rework in order to be more compatible with NPM (including the ability to directly require NPM packages from Meteor apps and packages), expected to be included in v1.3.
* (actually, Sacha Greif posted the quote).
This is from the docs:
In general, you must specify a package's version (e.g.,
'accounts#1.0.0' to use version 1.0.0 or a higher compatible version
(ex: 1.0.1, 1.5.0, etc.) of the accounts package). If you are sourcing
core packages from a Meteor release with versionsFrom, you may leave
off version names for core packages. You may also specify constraints,
such as my:forms#=1.0.0 (this package demands my:forms at 1.0.0
exactly), or my:forms#1.0.0 || =2.0.1 (my:forms at 1.x.y, or exactly
2.0.1).
So the answer is, it will not update your package.js script but it will download the latest compatible versions, depend on your settings.
I am having a sudden issue with installing Plone 4.2.4. I have pinned PloneFormGen to 1.7.11 but the buildout fails with the following error:
The version, 1.4.4, is not consistent with the requirement, 'plone.app.jquery>1.6'.
While:
Installing client1.
Error: Bad version 1.4.4
If I remove PFG from the buildout, it runs fine. I have pinned plone.app.jquery to 1.7.2 (even though it states its not compatible with < Plone 4.3) and the buildout runs successfully, but afterwards, if I update PloneFormGen from 1.7.6 to 1.7.11, it breaks the site.
The buildout is a standard Unified Installer build of Plone 4.2.4, using the out of the box version.cfg. I have extended this with my own config to add other components.
This build recipe I created months ago and it has worked flawlessly on other systems, but my most recent use of this recipe gives me the failures.
Any ideas would be greatly appreciated.
UPDATE:
I found an email on the Plone Users group by someone who was having a very similar issue to this. The fix seems to be to pin plone.app.jquery to 1.7.2 as well as pinning collective.js.jqueryui to 1.9.2.0. I did this and the issues I was experiencing appear to be resolved. However, I'm not comfortable with this solution as it appears to be an underlying issue with these two packages.
As you mentioned in your question update, you need to additionally pin plone.app.jquery to a newer version.
This is a fine solution and, if anything, PloneFormGen is just lacking in documentation so people are aware of it.
Please consider contributing to the README to help provide better instructions to install on the version of plone you're using: https://github.com/collective/Products.PloneFormGen/blob/master/Products/PloneFormGen/README.txt