Austin, version v0.x doesn't mean that project is not *stable*, in my point
of view everything published on npm should be stable (unstable should just
stay on github, or be published under different dedicated minor version,
like node does: even numbered stable, odd numbered experimental)
Versio
If the API has not settled yet, then wouldn't that mean the API is not
stable?
I think what semver asks is very reasonable: Tell us when you break
reverse compatibility. To do this, you can't use 0.x.x.
On Thursday, September 20, 2012 12:52:44 AM UTC-7, Mariusz Nowak wrote:
>
> Austin, version
On Sep 20, 2012 3:52 AM, "Mariusz Nowak" wrote:
>
> Austin, version v0.x doesn't mean that project is not *stable*, in my
point of view everything published on npm should be stable (unstable should
just stay on github, or be published under different dedicated minor
version, like node does: even n
> I think what semver asks is very reasonable
Maybe. I'm just saying the odds of it's requirements being widely adopted
are slim to none. I don't think many developers have noticed any problem
using 0.x.
I shouldn't be so negative though. Feel free to evangelize. I'll shut up.
On Thu, Sep 2
My experience with the node community has been that we love semver,
but have a slightly different definition than what's on the website.
If an npm module release is a bug-fix then the last digit is
incremented. If it's a API breaking change, then the middle digit is
incremented and the last digit
Library developers don't have any problem sticking with their current
scheme, it's not asking anything of them.
The problem comes in when I or other developers want to *use* those
libraries, and keep them up-to-date. You can't use features like "~1". And
this isn't just some nifty feature I'm p
On Thu, Sep 20, 2012 at 2:27 PM, Austin William Wright <
diamondma...@users.sourceforge.net> wrote:
> The problem comes in when I or other developers want to *use* those
> libraries, and keep them up-to-date. You can't use features like "~1".
>
You know when you're using a module that's in a 0.x
Perhaps this is how it has come to be used, but unfortunately "young and
growing" doesn't tell me anything useful about a project once I begin using
it. Nor is "architectural change" versus "breaking change" a distinction
that an application cares about.
Also if you use the minor version number
By this formula, Node has been 1.0+ since day one and never broken
backwards compatibility... Its understandable that young projects
hover below 1.0 in order to get a more throughly designed API in place
(and maybe fix/remove API kinks that were bad ideas at one point in
time)... but some would say
I was going to suggest some version numbers that Node.js could have gone
with, but it's not really my place to say something like that. However,
Node.js appears to have largely ended it's rapid-breakage phase around
0.4.0 at the latest.
There hasn't been any major overhauls, however I've still
For what it's worth, I see the value in using all three numbers to
their fullest potential as the spec describes.
Also I explained my usage of node-style semver incorrectly and I apologize.
My personal standard is I bump the last digit for both bug fixes and
feature additions. Basically any chan
The problem is packages don't use this consistently, and don't even make an
effort to tell us of breaking changes. 0.x.x is supposed to mean, and often
does mean, the package is in a period of rapid API breakage. But many
packages simply use it as an excuse to break their API whenever they want.
On Thu, Sep 20, 2012 at 2:59 PM, Austin William Wright <
diamondma...@users.sourceforge.net> wrote:
> Also if you're releasing versions with a 0. prefix then what's the point?
> You're dropping the indication of new feature releases, just so you can
> have a leading 0.? This inconsistency is confu
The API *does not need to be *what you definitely want. If you decide to
later change the API, just release 2.0.0. The important part is that you
tell us clearly that the API broke. That's all that matters.
On Thursday, September 20, 2012 12:04:10 PM UTC-7, Scott González wrote:
>
> On Thu, Sep
On Thu, Sep 20, 2012 at 3:10 PM, Austin William Wright <
diamondma...@users.sourceforge.net> wrote:
> The API *does not need to be *what you definitely want. If you decide to
> later change the API, just release 2.0.0. The important part is that you
> tell us clearly that the API broke. That's all
Certainly making a distinction between an architectural change/rewrite is
important for many reasons. But I don't think it's a distinction we need to
split out in the version number. Developers are more inclined to be able to
use out-of-bound information than the program, for example, we
unders
If more than a dozen people are using your package, then next time you make
a breaking change, release 1.0.0. Continue to clearly identify when you
make breaking changes, when you release new features, and when you release
a patch.
That'd help tremendously with the package ecosystem, I believe.
On Thu, Sep 20, 2012 at 2:25 PM, Austin William Wright
wrote:
> If more than a dozen people are using your package, then next time you make
> a breaking change, release 1.0.0. Continue to clearly identify when you make
> breaking changes, when you release new features, and when you release a
> pat
> 2. Migrate from architecture-change.breaking-change.non-breaking-change
numbers to breaking-change.non-breaking-feature-addition.bug-fix numbers.
I realized, I haven't seen this scheme before today, at least not as you
explain. It *seems* to explain why people are hesitant to release a versio
Actually, I don't tag my dependencies like that either, I use Git
submodules, so I know exactly, byte-for-byte what code I'm distributing.
This doesn't eliminate the need for upgrading packages from time to time. I
need to be able to run an "git node update" command and have 20 packages
update,
I think one way we disagree is in the definition of "standard". All npm
guarantees is that the version by *parseable* by node-semver, not that they
follow the complete semver specification.
It may not be a documented "standard", but what Tim alludes to,
architecture-change.breaking-change.non-brea
I guess that's what I'm advocating against: Using some scheme without any
documentation of it makes your program unpredictable. And not just runtime
unpredictable (at least we can always refer to the ultimate documentation,
the source code), but we don't know how well it will upgrade in the futu
I don't disagree with you insofar as using something that *looks like *semver
without *being *semver can be confusing.
However, what I do disagree with is the attitude that we should change *common
practice* because there is a similar-looking *standard*. Does that make
sense? It's one thing to be
I'll apply my same thinking under Rails/rubygems/bundler to node/npm. I don't
ever look at version numbers of gems I use, or NPM modules now that I've
started doing some node too. I install them, version control them and write
tests. If my app works with the dependencies at the versions I instal
Semver used by most all the packages that I depend on. The problem is that
(1) most of these dependencies are on ~0 and feel free to break their API
any time without warning (this is what they tell me), and (2) those that
don't use semver, *don't disclose any scheme at all.* It is not documented
For production applications, having tests and maintaining dependencies is a
good idea. However I explained this isn't a replacement for the major
version number:
(1) Not everyone is writing production applications. My own ~0 application
in production moves too fast for tests to be meaningful.
> developers should be able to identify at a glance which version is
breaking, and which is not
You sure have a lot of faith in the developers. I would never trust any
version numbering scheme. When I need a new feature or a bug-fix I test
the latest version. I don't even pay attention to versi
I never said you need to trust the library developer, but that's no excuse
for them to mis-identify which versions are breaking, and which are stable.
You want to update to the latest package that's compatible with your
current version. What's the easiest way to do that? I should not need to
tr
> You want to update to the latest package that's compatible with your
current version.
I don't understand why you would want to do that. You are taking a risk
for no reason.
I only update when I need a feature or some bug is discovered. In either
case I may need to change my code or may not.
Well then you have no need for version numbers at all, what are you
complaining about?
Some of us, however, do rely on upgrading packages. Some of use multiple
packages that require() the same module, we need a way to resolve which
package is mutually compatible. You can't make broad assumption
On 9/20/12 2:30 PM, Scott González wrote:
On Thu, Sep 20, 2012 at 2:27 PM, Austin William Wright
mailto:diamondma...@users.sourceforge.net>> wrote:
The problem comes in when I or other developers want to /use/ those
libraries, and keep them up-to-date. You can't use features like "~1".
So, there are two topics here that are both very interesting, in my opinion.
1. When publishing an app, you should freeze your dependencies to
something that you know works. In varying degrees of frozenness, that
can be done via: a) checking node_modules into git, b) using npm
shrinkwrap, c) depe
+1
Le jeudi 20 septembre 2012 21:54:40 UTC+2, Tim Caswell a écrit :
>
> On Thu, Sep 20, 2012 at 2:25 PM, Austin William Wright
> > wrote:
> > If more than a dozen people are using your package, then next time you
> make
> > a breaking change, release 1.0.0. Continue to clearly identify when yo
33 matches
Mail list logo
