I am currently using dgrid 0.3.21 and everything is working fine in our project.
dgrid 0.3, 0.4 and 1.x seem to be maintained in parallel.
Is there any information on how long 0.3 will be maintained?
Does anyone know advantages of the new versions?
If the new versions are worth it, we could migrate. But I don’t see any advantages.
Related
The rules for when to increase the MAJOR vs the MINOR version number with SemVer 2.0 are very compelling. They clearly give a lot of advantages to knowing if the app/service is backwards compatible.
But the site does not really give an reason for the differences between a MINOR and what it calls a PATCH. I don't see it giving the same benefits of MAJOR vs MINOR.
For reference here are the SemVer rules:
MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.
So the only difference between MINOR and PATCH is features vs bug fixes. My company wants to do that differently.
They want to have MINOR be a collection of [backwards compatible] features. "PATCH" (which we call Incremental) be the releases needed to get those features out. (We release bug fixes as we release features.)
For example, if we plan for 7 [backwards compatible] features in our 2.4 release then 2.4.0 may have 2 of the features, 2.4.1 would have 3 more features and 2.4.2 would have the last 2 (perhaps with a bug fix or two in each release).
I can see that this violates SemVer, but I need to know why SemVer has decided to be prescriptive on the differences between the MINOR and PATCH versions so I can know which way to push my company.
NOTE: I hope that this is not too subjective for Stack Overflow. I don't usually ask questions like this, so it is possible that this question will need to be closed...
The standard is deliberately terse. There's nothing in it that prevents you from releasing a bunch of bug fixes along with your new features and you only have to bump the minor field when you do this. If the changes only involve bug fixes, refactoring or documentation that does not add, remove or modify any interface, then you only bump the patch. The whole point is to communicate to your consumers, their level of risk when taking an update from you.
EDIT:
It is a best practice to separate bug fixes (patches) from feature work (minor) and breaking changes (major), into separate releases. This allows your consumers to automatically pick up the latest fixes, without having to deal with feature bloat or breaking changes.
For example, if we plan for 7 [backwards compatible] features in our 2.4 release then 2.4.0 may have 2 of the features, 2.4.1 would have 3 more features and 2.4.2 would have the last 2 (perhaps with a bug fix or two in each release).
Nothing stops you following SemVer convention and release 2.4.0 with 2 features, 2.5.0 with 3 more features and 2.6.0 with last 2 features and a few bug fixes for previously released features.
It is better to follow some common convention instead of reinventing the wheel. You save time thinking, discussing and documenting a custom solution as well as avoid confusion within the team and newcomers.
https://semver.org/
Murphy kicked my a$$ about an hour ago.
Context:
I recently joined a new employer and the product was quite outdated in terms of dependencies, Angular 1.2.x, Angular-UI 0.12.0, etc...
This is the first employer I've worked at that does daily builds to prod etc. (previosuly I've only worked in what can be called large corporate, with much slower turn around) Part of my initial task was to upgrade dependencies where I can. Thus earlier this morning we had a watercooler talk with some of the devs about why all of our bower dependencies are hardcoded to specific versions.
The 2 schools of thought are:
Hardcoding versions obviously gives 100% security as versions can't dynamically jump, but has the drawback that if someone doesnt actively update we'll fall behind again.
I'm of the opinion that semantic versioning gives us some form of security (coupled with having multiple staging environments), and that it should be good enough to, say, have Angular set to say ^1.5.9.
Quoted from the Semantic Version Docs:
Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards
compatible functionality is introduced to the public API. It MUST be
incremented if any public API functionality is marked as deprecated.
It MAY be incremented if substantial new functionality or improvements
are introduced within the private code. It MAY include patch level
changes. Patch version MUST be reset to 0 when minor version is
incremented.
Problem:
Earlier this morning we deployed to staging, and everything seemed good to go, then we deployed to production an hour or so ago and ... BOOM
The issue was the AngularJs change from 1.5.9, to 1.6.0. I've seen in the migration docs (migrate 1.5 -> 1.6) that this has been noted:
You may also notice that this release comes with a longer-than-usual
list of breaking changes. Don't let this dishearten you though, since
most of them are pretty minor - often not expected to affect real
applications. These breaking changes were necessary in order to:
Question:
Where is my disconnect? ...or is the semantic version docs just a false sense of security I've had all along?
How do people out there in the handle these situations? Do people make use of auto dependency upgrading in any real world solutions (excuse me if this is super obvious to some), as to me, the fact that the build passed staging, and broke in production is actually more concerning.
(The reason I'm asking is because the fear of small incremental updates are now back and stronger than ever, and I'm not sure if I agree with the sentiment of it all...)
Seems pretty simple, if they make breaking changes, they should have bumped it up to 2.0.0. They are not doing semantic versioning. Not all projects using X.Y.Z. style versions are doing semantic versioning.
Try to catch how this went "boom" in an automated way in your testing and staging environments. Can't fear moving forward, it has to be done sometime, and I'd rather move step-by-step more frequently, than to suddendly move up many versions as would be done with an entirely manual process.
I'm trying to get started with some grids using dgrid-0.4 and having trouble getting them to talk to a store. My project already uses dstore-1.1 and I was hoping to wire it up to this, however bower informs me that it wants 1.0.x as a dependency. I don't know if my woes are through some other ineptitude or because it really does need the older version. Should it work ever with the current dstore release?
At the time dgrid 0.4 was released, ~1.0 was listed as its dstore dependency in bower.json to safeguard against any potential breaking changes in 1.1+. However, in our testing with dgrid 0.4 and dstore 1.1, it should be safe to use, and we'll be updating the dependency listed in dgrid's bower.json for future releases.
If bower presents you with a conflict, it should give you the option of choosing between the dependency dgrid lists, or the other dependency you want (1.1.0). It should be safe to choose the latter. You can also store this decision in your bower.json with the resolutions property.
Coworkers have a lot of old-fashion gnuplot scripts working fine with gnuplot 4.1. It would be neat to update to 4.6 to get the for-loop functionality and the beauty of new terminals.
Have you ever faced compatibility issue while updating gnuplot ?
Is there something to add to ~/.gnuplot to ensure backward compatibility ?
Thank's for your help, I have to convince coworkers that this is a safe transition.
Note :
A change of behavior is described in (gnuplot script fails - has there been a change in defaults from 4.4 to 4.6) column header. This is an examples of troubles you may have encountered, that kind of glitch I have to take into account and warn people about.
The amount of effort to update the scripts really depends on how many tricks your coworkers use which exploit bugs that were later patched in gnuplot. In my experience (almost) anything that works in gnuplot 4.0 works in 4.6/4.7, just not the other way around.
This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 10 years ago.
The community reviewed whether to reopen this question 1 year ago and left it closed:
Original close reason(s) were not resolved
What is the versioning style of the project?
You should only be using even numbered versions: x.[even].z. These are all "stable" and bug fixes will be released to them (until the next minor version). Only the latest x.[even].z version is supported at any given time.
For compatibility, you should just look at the documentation. For example, for events: http://nodejs.org/api/events.html
Stability: 4 - API Frozen
That means you can be rest assured that the EventEmitter class will never change.
Then there's stuff like domains where no one is sure what they're doing, and you probably shouldn't be using it:
Stability: 1 - Experimental
Your best best is just to stick with Stability >= 3 features and not worry about compatibility between versions.
Also, there doesn't seem to be a strict release cycle.
Node has a two-track versioning system. Even-numbered versions (0.4, 0.6, 0.8) are stable, and odd-numbered versions are unstable. The stable releases are API-stable, which means that if you are using 0.8.1 and 0.8.2 comes out, you should be able to upgrade with no issues.
On the 0.9.x stream, any update may change the API, especially in parts of the system that are under active development. When the odd-version reaches a certain level of stability and maturity, it becomes the next even-version.
There is not a strict timed-release cycle. The primary maintainer of Node.JS is a guy named Isaac Schleuter and he has been very public about his goals and targets with node. He is also open to a lot of community input on this, so they run NodeConf and Node Summer Camp and some other events to gather input.
If you have time to really dig into the community, check out the NodeUp podcast and some of Isaac's talks to get an idea about the direction they are going and APIs.
You ask about version 1.0. As far as I remember, Isaac has a couple of specific things he wants to stabilize before going to version 1.0. In particular, I remember Streams and Buffers which have really become key to node's growth. (that's stated, this just from memory)