Skip to main content
Commonmark migration
Source Link

It requires a public API in order to effectively apply it's versioning pattern.

For example:

Bug fixes not affecting the API increment the patch version

 

Backwards compatible API additions/changes increment the minor version, and...

 

Backwards incompatible API changes increment the major version.

What represents your API is subjective, as they even state in the SemVer doc:

This may consist of documentation or be enforced by the code itself.

I think that is where your misunderstanding is. An API is not necessarily...

a part of the site designed for other developers that allow them to query my website and get the result into structured data

It could be that. Who knows. It could also be a set of documented UX rules.

If you can't effectively outline what your website's API is, then maybe SemVer isn't appropriate.

It requires a public API in order to effectively apply it's versioning pattern.

For example:

Bug fixes not affecting the API increment the patch version

 

Backwards compatible API additions/changes increment the minor version, and...

 

Backwards incompatible API changes increment the major version.

What represents your API is subjective, as they even state in the SemVer doc:

This may consist of documentation or be enforced by the code itself.

I think that is where your misunderstanding is. An API is not necessarily...

a part of the site designed for other developers that allow them to query my website and get the result into structured data

It could be that. Who knows. It could also be a set of documented UX rules.

If you can't effectively outline what your website's API is, then maybe SemVer isn't appropriate.

It requires a public API in order to effectively apply it's versioning pattern.

For example:

Bug fixes not affecting the API increment the patch version

Backwards compatible API additions/changes increment the minor version, and...

Backwards incompatible API changes increment the major version.

What represents your API is subjective, as they even state in the SemVer doc:

This may consist of documentation or be enforced by the code itself.

I think that is where your misunderstanding is. An API is not necessarily...

a part of the site designed for other developers that allow them to query my website and get the result into structured data

It could be that. Who knows. It could also be a set of documented UX rules.

If you can't effectively outline what your website's API is, then maybe SemVer isn't appropriate.

added 98 characters in body
Source Link
BrandonV
  • 1.4k
  • 1
  • 10
  • 15

It requires a public API in order to effectively apply it's versioning pattern.

For example:

Bug fixes not affecting the API increment the patch version

Backwards compatible API additions/changes increment the minor version, and...

Backwards incompatible API changes increment the major version.

What represents your API is subjective, as they even state in the SemVer doc:

This may consist of documentation or be enforced by the code itself.

I think that is where your misunderstanding is. An API is not necessarily...

a part of the site designed for other developers that allow them to query my website and get the result into structured data

It could be that. Who knows. It could also be a set of documented UX rules.

If you can't effectively outline what your website's API is, then maybe SemVer isn't appropriate.

It requires a public API in order to effectively apply it's versioning pattern.

For example:

Bug fixes not affecting the API increment the patch version

Backwards compatible API additions/changes increment the minor version, and...

Backwards incompatible API changes increment the major version.

What represents your API is subjective, as they even state in the SemVer doc:

This may consist of documentation or be enforced by the code itself.

I think that is where your misunderstanding is. An API is not necessarily...

a part of the site designed for other developers that allow them to query my website and get the result into structured data

If you can't effectively outline what your website's API is, then maybe SemVer isn't appropriate.

It requires a public API in order to effectively apply it's versioning pattern.

For example:

Bug fixes not affecting the API increment the patch version

Backwards compatible API additions/changes increment the minor version, and...

Backwards incompatible API changes increment the major version.

What represents your API is subjective, as they even state in the SemVer doc:

This may consist of documentation or be enforced by the code itself.

I think that is where your misunderstanding is. An API is not necessarily...

a part of the site designed for other developers that allow them to query my website and get the result into structured data

It could be that. Who knows. It could also be a set of documented UX rules.

If you can't effectively outline what your website's API is, then maybe SemVer isn't appropriate.

Source Link
BrandonV
  • 1.4k
  • 1
  • 10
  • 15

It requires a public API in order to effectively apply it's versioning pattern.

For example:

Bug fixes not affecting the API increment the patch version

Backwards compatible API additions/changes increment the minor version, and...

Backwards incompatible API changes increment the major version.

What represents your API is subjective, as they even state in the SemVer doc:

This may consist of documentation or be enforced by the code itself.

I think that is where your misunderstanding is. An API is not necessarily...

a part of the site designed for other developers that allow them to query my website and get the result into structured data

If you can't effectively outline what your website's API is, then maybe SemVer isn't appropriate.