search

esvit / ng-table

Simple table with sorting and filtering on AngularJS
http://esvit.github.io/ng-table
BSD 3-Clause "New" or "Revised" License
2.77k stars 851 forks source link

Is v4.0.0 not stable? #953

Closed kyrylkov closed 7 years ago

kyrylkov commented 7 years ago

Is v4.0.0 not stable and v3.0.1 the latest stable as of 2007-01-05?

christianacca commented 7 years ago

Well both should be stable, but 4.0.0 introduced some more substantial breaking changes. By publishing 4.0.0 with the 'next' dist-tag, any problems that people experience will be to a smaller group of devs.

So my advice:

On Thu, Jan 5, 2017 at 1:28 PM, Sergiy Kyrylkov notifications@github.com wrote:

Is v4.0.0 not stable and v3.0.1 the latest stable as of 2007-01-05?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/esvit/ng-table/issues/953, or mute the thread https://github.com/notifications/unsubscribe-auth/AA2HPpyWXlnjl4XPtVVgsGDL1uVYB7Zdks5rPO_ugaJpZM4Lbr-s .

kyrylkov commented 7 years ago

Does ng-table use semantic versioning?

If yes, it's understood that 4.0.0 has some breaking changes.

What's confusing in this case is that npm out shows that 3.0.1 is the latest, when ~4.0.0 is required in package.json:

Package   Current  Wanted  Latest  
ng-table    4.0.0   4.0.0   3.0.1

Also the fact that 4.0.0 is marked as a pre-release in GitHub just adds to the confusion.

I suggest you release 4.0.1 and mark it as a regular release so it becomes the latest release solving both issues outlined above.

ccrowhurstram commented 7 years ago

The project uses semantic-release to automate version number assignment and to publish to npm. This dictates certain conventions.

One of which is NOT to use pre-release version numbers but instead use release channels via npm dist-tags to indicate whether the version is considered "battle tested". Interestingly, this is what the npm team uses itself to version the npm client.

For ng-table, this leads to the following...

Publishing work flow

  1. a new version is published with a version number that reflects whether this version introduces a fix, feature, or breaking change (eg 4.0.0)
  2. this new version is published with a dist-tag of next
    • note: any new installs of ng-table will continue to use the current version tagged with latest (eg 3.0.1)
  3. the release on github is marked as pre-release
    • the alternative would be to not add a pre-release marker - I'm not sure that is a good idea, and it's not something that the npm project follows
  4. a period of time elapses where a small(er) proportion of app's have installed / updated to this next version; no adverse feedback is received
  5. the dist-tag of this version is now changed to latest and the pre-release marker is removed from github
  6. any new installs will use this version (eg 4.0.0)

Unfortunately tooling is not perfect. npm doesn't place meaning on the dist-tags and so npm out says what it says.

C

christianacca commented 7 years ago

I've added a small clarification to the readme that points to this conversation.

Hopefully, that will clear up some of the confusion for others

kyrylkov commented 7 years ago

That's great. Thank you for investing your time into this project.

christianacca commented 7 years ago

Cool. I'll close this issue now.