You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a follow up to #940 (thanks for the quick fix!) and the accidental issues that arose there due to some liberal dependencies in karma and related packages along with some breaking updates in new versions I'm wondering what the plan is for getting to a 1.0.0 release?
The Semantic Versioning specification, http://semver.org/, that all npm modules should use, defines all 0.y.z releases as having an unstable public API and all new versions to therefor possibly be incompatible. That makes issues like the recent one a bit tough to properly solve.
About a 1.0.0 version it says:
How do I know when to release 1.0.0?
If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you're worrying a lot about backwards compatibility, you should probably already be 1.0.0.
To me it feels like karma is becoming such a widely used project that backwards compatibility is very much a concern and that it is very much a software used in production – as showed by mine and others reaction on #940 and some of the slight panic shown when CI-environments and such all of the sudden began to complain.
With a 1.0.0 release the API that people already perceive as stable would officially become so from a npm and Semantic Versioning perspective as well and one can easily define the need for a compatible version of it in ones dependencies. That is what npm now does by default on a --save or --save-dev since some time ago by using the new ^ version range – like ^1.0.0 (see https://github.com/isaacs/node-semver#ranges) – and would be great if such an important project as karma would play along well with that.
The text was updated successfully, but these errors were encountered:
better APIs (more strict) for plugins (currently this is very powerful, but also very fragile)
parallelization
Now, about breaking changes. I do care about it. This is a tough problem to solve. Semver won't solve it. Semver wouldn't solve #940 either.
I'm gonna write down my thoughts (including concrete steps how to improve the stability of Karma). Will post it here and then, we can decide what to do.
As a follow up to #940 (thanks for the quick fix!) and the accidental issues that arose there due to some liberal dependencies in karma and related packages along with some breaking updates in new versions I'm wondering what the plan is for getting to a 1.0.0 release?
The Semantic Versioning specification, http://semver.org/, that all npm modules should use, defines all 0.y.z releases as having an unstable public API and all new versions to therefor possibly be incompatible. That makes issues like the recent one a bit tough to properly solve.
About a 1.0.0 version it says:
To me it feels like karma is becoming such a widely used project that backwards compatibility is very much a concern and that it is very much a software used in production – as showed by mine and others reaction on #940 and some of the slight panic shown when CI-environments and such all of the sudden began to complain.
With a 1.0.0 release the API that people already perceive as stable would officially become so from a npm and Semantic Versioning perspective as well and one can easily define the need for a compatible version of it in ones dependencies. That is what npm now does by default on a
--save
or--save-dev
since some time ago by using the new^
version range – like^1.0.0
(see https://github.com/isaacs/node-semver#ranges) – and would be great if such an important project as karma would play along well with that.The text was updated successfully, but these errors were encountered: