New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Please use proper semantic versioning #3252

Closed
Whoaa512 opened this Issue Feb 15, 2017 · 14 comments

Comments

Projects
None yet
8 participants
@Whoaa512

Whoaa512 commented Feb 15, 2017

This is a Bug Report & Feature Proposal

Description

Breaking changes were introduced in v1.6 which should have resulted in the framework being bumped to v2. It is not acceptable to break users through minor version bumps, especially since your framework sits at a foundational level in a deployment stack, and you have clearly stated in your docs that you follow semver.

Please stop releasing breaking changes as minor version bumps. This breaks deploys for people consuming your cli/framework via npm or yarn.

Proper semver is as follows (Source)

Given a version number MAJOR.MINOR.PATCH, increment the:

  • 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.
  • Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

No additional config is required, just some discipline around releases.

@dncrews

This comment has been minimized.

Show comment
Hide comment
@dncrews

dncrews Feb 15, 2017

I came here to report this EXACT issue. Here is a comment shown during installation.

  WARNING: You are running v1.7.0. v1.8.0 will include the following breaking changes:
    - Will replace IamPolicyLambdaExecution resource with inline policies -> https://git.io/vDilm
    - "sls info" will output the short function name rather than the lambda name -> https://git.io/vDiWx

Breaking changes on minor releases is why my employer has trust issues. npm assumes semver, so you get installed as "^1.7.0", so breaking changes really do break builds.

According to your members, you follow semver, yet here we are.

dncrews commented Feb 15, 2017

I came here to report this EXACT issue. Here is a comment shown during installation.

  WARNING: You are running v1.7.0. v1.8.0 will include the following breaking changes:
    - Will replace IamPolicyLambdaExecution resource with inline policies -> https://git.io/vDilm
    - "sls info" will output the short function name rather than the lambda name -> https://git.io/vDiWx

Breaking changes on minor releases is why my employer has trust issues. npm assumes semver, so you get installed as "^1.7.0", so breaking changes really do break builds.

According to your members, you follow semver, yet here we are.

@Whoaa512

This comment has been minimized.

Show comment
Hide comment
@Whoaa512

Whoaa512 Feb 17, 2017

I also I would like to add that I believe it's perfectly fine to have many major version bumps, so long as semver is respected, and breaking changes are clearly noted :)

Whoaa512 commented Feb 17, 2017

I also I would like to add that I believe it's perfectly fine to have many major version bumps, so long as semver is respected, and breaking changes are clearly noted :)

@robconery

This comment has been minimized.

Show comment
Hide comment
@robconery

robconery Feb 17, 2017

100% YES. This deserves to be pinned and understood completely. Being positive: this framework (while young) is enabling a lot of very interesting possibilities for people just like me: trying to get a business off the ground and keeping things simple. Breaking changes can hurt, badly.

I would urge you to 1) remove that warning and 2) make v1.8 v2.

robconery commented Feb 17, 2017

100% YES. This deserves to be pinned and understood completely. Being positive: this framework (while young) is enabling a lot of very interesting possibilities for people just like me: trying to get a business off the ground and keeping things simple. Breaking changes can hurt, badly.

I would urge you to 1) remove that warning and 2) make v1.8 v2.

@jokeyrhyme

This comment has been minimized.

Show comment
Hide comment
@jokeyrhyme

jokeyrhyme Feb 24, 2017

According to some of the documentation, it would seem that this project is versioned according to SemVer guidelines:

It would be terrific if some consensus around the versioning scheme could be reached, whether this is Semver or not, and documentation updated to reflect this.

jokeyrhyme commented Feb 24, 2017

According to some of the documentation, it would seem that this project is versioned according to SemVer guidelines:

It would be terrific if some consensus around the versioning scheme could be reached, whether this is Semver or not, and documentation updated to reflect this.

@dncrews

This comment has been minimized.

Show comment
Hide comment
@dncrews

dncrews Mar 16, 2017

@pmuens @nikgraf Where's the semver you promised?

dncrews commented Mar 16, 2017

@pmuens @nikgraf Where's the semver you promised?

@fakewaffle

This comment has been minimized.

Show comment
Hide comment
@fakewaffle

fakewaffle Mar 21, 2017

From an email sent by the Serverless team:

Breaking Changes - We're no longer following strict semver. You can always find the most recent list of breaking changes in the upcoming milestone or in the Serverless CLI.

With Serverless being a Node project and published to NPM it seems like a horrible idea to not follow semver.

fakewaffle commented Mar 21, 2017

From an email sent by the Serverless team:

Breaking Changes - We're no longer following strict semver. You can always find the most recent list of breaking changes in the upcoming milestone or in the Serverless CLI.

With Serverless being a Node project and published to NPM it seems like a horrible idea to not follow semver.

@devtanc

This comment has been minimized.

Show comment
Hide comment
@devtanc

devtanc Mar 21, 2017

100% Agreed. I don't see why it's "Hey we're adopting strict semver" in November, then 3 months later it's back to non-semver. It's not that hard to follow.

devtanc commented Mar 21, 2017

100% Agreed. I don't see why it's "Hey we're adopting strict semver" in November, then 3 months later it's back to non-semver. It's not that hard to follow.

@chevex

This comment has been minimized.

Show comment
Hide comment
@chevex

chevex Mar 22, 2017

+1 please be professional about your versioning. Semver is not that hard to follow.
Surely saying "¯\(ツ)/¯ we no longer follow strict semver" and upsetting people that use your package must be more trouble than just following proper semver guidelines??

chevex commented Mar 22, 2017

+1 please be professional about your versioning. Semver is not that hard to follow.
Surely saying "¯\(ツ)/¯ we no longer follow strict semver" and upsetting people that use your package must be more trouble than just following proper semver guidelines??

@jokeyrhyme

This comment has been minimized.

Show comment
Hide comment
@jokeyrhyme

jokeyrhyme Mar 22, 2017

When developing libraries, services, or anything where the focus is on a developer API, then SemVer is a terrific help to those downstream developers

When developing a product, that end-users see, SemVer can be very confusing, as you often reserve a "big number increment" for a release event with fanfair, perhaps a rewrite or a redesign

We're in a tricky overlap of these two, as Serverless is a product but it is intended to be used by developers, and using it requires those developers to depend on certain details

I'm glad there's a definitive non-SemVer statement, and I understand why Serverless is taking this approach. It disappoints me a little, but I understand why, and Serverless still beats doing all this work any other way.

jokeyrhyme commented Mar 22, 2017

When developing libraries, services, or anything where the focus is on a developer API, then SemVer is a terrific help to those downstream developers

When developing a product, that end-users see, SemVer can be very confusing, as you often reserve a "big number increment" for a release event with fanfair, perhaps a rewrite or a redesign

We're in a tricky overlap of these two, as Serverless is a product but it is intended to be used by developers, and using it requires those developers to depend on certain details

I'm glad there's a definitive non-SemVer statement, and I understand why Serverless is taking this approach. It disappoints me a little, but I understand why, and Serverless still beats doing all this work any other way.

@dncrews

This comment has been minimized.

Show comment
Hide comment
@dncrews

dncrews Mar 22, 2017

I understand the sentiment, but I disagree with your conclusion. There is no crossover. Serverless is ONLY a library. No "end user" will ever see this, and the ONLY way to interact with it is through the API. Looking at their documentation and tutorials they are first and foremost an NPM package, and when you install it, NPM defaults to ^version, meaning their "breaking changes" actually break people.

I understand why they're choosing this too, but I propose they are incorrect in thinking this is a product. It is a deployment API, and they are being reckless with real people's money by not understanding that stability is important.

dncrews commented Mar 22, 2017

I understand the sentiment, but I disagree with your conclusion. There is no crossover. Serverless is ONLY a library. No "end user" will ever see this, and the ONLY way to interact with it is through the API. Looking at their documentation and tutorials they are first and foremost an NPM package, and when you install it, NPM defaults to ^version, meaning their "breaking changes" actually break people.

I understand why they're choosing this too, but I propose they are incorrect in thinking this is a product. It is a deployment API, and they are being reckless with real people's money by not understanding that stability is important.

@fakewaffle

This comment has been minimized.

Show comment
Hide comment
@fakewaffle

fakewaffle Mar 22, 2017

When developing a product, that end-users see, SemVer can be very confusing, as you often reserve a "big number increment" for a release event with fanfair, perhaps a rewrite or a redesign

I agree with that 100%, but Serverless is not a consumer or end-users product. At all. #fakenews

fakewaffle commented Mar 22, 2017

When developing a product, that end-users see, SemVer can be very confusing, as you often reserve a "big number increment" for a release event with fanfair, perhaps a rewrite or a redesign

I agree with that 100%, but Serverless is not a consumer or end-users product. At all. #fakenews

@robconery

This comment has been minimized.

Show comment
Hide comment
@robconery

robconery Mar 22, 2017

I dropped this project last week for this very issue. A few shell scripts and a lot less YAML and I'm off and running.

SemVer can be very confusing

Yeah whatever.

robconery commented Mar 22, 2017

I dropped this project last week for this very issue. A few shell scripts and a lot less YAML and I'm off and running.

SemVer can be very confusing

Yeah whatever.

@smcgee31

This comment has been minimized.

Show comment
Hide comment
@smcgee31

smcgee31 Mar 22, 2017

Obviously I'll do whatever my employer decides, but as a new developer for any personal projects I think I better stay away from serverless for now. Hope word doesn't spread too far before you decide to fix this.

smcgee31 commented Mar 22, 2017

Obviously I'll do whatever my employer decides, but as a new developer for any personal projects I think I better stay away from serverless for now. Hope word doesn't spread too far before you decide to fix this.

@devtanc

This comment has been minimized.

Show comment
Hide comment
@devtanc

devtanc Mar 22, 2017

When developing a product, that end-users see, SemVer can be very confusing, as you often reserve a "big number increment" for a release event with fanfair, perhaps a rewrite or a redesign

I agree with @fakewaffle entirely on this one. What user group is utilizing Serverless who would not understand, or be incapable of learning SemVer? It being a cli product installed via package manager, your user base is limited to those who know the command line and are comfortable using a package manager. Anyone in that bucket who doesn't know SemVer, should learn it to understand what they're getting into when installing packages.

Just stop saying Serverless Framework Version 1.0 just say it's the Serverless Framework. Don't tie it to the versioning until you are stable enough to be able to follow SemVer and not have a major version change every month.

Yeah, we were all excited when you went to 1.0, but I think most of us were more excited when you made the decision to follow strict SemVer.

devtanc commented Mar 22, 2017

When developing a product, that end-users see, SemVer can be very confusing, as you often reserve a "big number increment" for a release event with fanfair, perhaps a rewrite or a redesign

I agree with @fakewaffle entirely on this one. What user group is utilizing Serverless who would not understand, or be incapable of learning SemVer? It being a cli product installed via package manager, your user base is limited to those who know the command line and are comfortable using a package manager. Anyone in that bucket who doesn't know SemVer, should learn it to understand what they're getting into when installing packages.

Just stop saying Serverless Framework Version 1.0 just say it's the Serverless Framework. Don't tie it to the versioning until you are stable enough to be able to follow SemVer and not have a major version change every month.

Yeah, we were all excited when you went to 1.0, but I think most of us were more excited when you made the decision to follow strict SemVer.

@Whoaa512 Whoaa512 closed this Nov 9, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment