
Semantic Versioning 2.0.0 (2013) - jbernardo95
http://semver.org/
======
mmebane
This appears to be from 2013:
[https://github.com/mojombo/semver/commits/v2.0.0](https://github.com/mojombo/semver/commits/v2.0.0)

------
SimonPStevens
I've been at so many companies where someone is pushing to adopt semantic
versioning without actually following step 1 in the spec...

> 1\. Software using Semantic Versioning MUST declare a public API. This API
> could be declared in the code itself or exist strictly in documentation.
> However it is done, it should be precise and comprehensive.

SemVer doesn't even make sense if you don't have a public API. SemVer doesn't
make sense for end user products that don't have an API. I really wish people
would stop trying to abuse it.

~~~
dudul
I'm pretty sure they mean "API" in its true sense. An API for a module or a
library, not necessarily a Web API. It's not unusual for an organization to
maintain several projects/libraries/services that interact internally via
their APIs (sometimes over HTTP, sometimes directly as a library), SemVer
makes perfect sense for this use case.

~~~
fenomas
They mean API in the sense of anything that someone can declare a dependency
against.

Whether it's a web service or a library is immaterial; the point of the thing
is to be able to update something and formally tell any downstream
dependencies whether the update breaks compatibility or not.

------
STRML
See
[https://github.com/mojombo/semver/compare/v1.0.0...v2.0.0](https://github.com/mojombo/semver/compare/v1.0.0...v2.0.0)
for the changelog.

Edit: Changes, that is, not a changelog.

~~~
CaliforniaKarl
I don't think that's a changelog. That is a collection of git commits, where
the intended audience is primarily the developers of the work.

A changelog, by comparison, is meant for clients who use the work.

See also
[https://github.com/mojombo/semver/issues/387](https://github.com/mojombo/semver/issues/387)
and [http://keepachangelog.com/en/1.0.0/](http://keepachangelog.com/en/1.0.0/)

~~~
STRML
Yes, you're correct, it's not a changelog - rather, it is the changes.

Click "Files changed" for an actual diff. I am not sure what makes it v2.0.0,
however.

------
Dreami
We probably need a changelog

~~~
jrochkind1
[http://keepachangelog.com/en/1.0.0/](http://keepachangelog.com/en/1.0.0/)

------
eggs_and_avo
Check out Compatible Versioning 1.0 (2016):
[https://github.com/staltz/comver](https://github.com/staltz/comver)

------
panic
Are there any projects that follow this specification strictly? It seems like
most projects are willing to do backwards-incompatible "bug fixes" to the
behavior of their API without incrementing the major version. These are
usually harmless in practice, but technically break rule 8. It seems difficult
to me to prove that any given set of changes can't break someone else's code
(even allocating an extra byte of memory has the potential to do this).

~~~
bartread
The thing I find most frustrating about semantic version is that even under
the strictest adoption it overly legitimizes breaking changes across major
versions.

I see far too much refactoring of JS library APIs that is essentially
aesthetic across major versions - D3 and Angular spring immediately to mind (I
understand the scalability justification for Angular; I just don't really
believe it).

To me, having an elegant API is not the highest concern because what I'm
interested in is building products, and from that point of view stability is
much more important. I _do not_ appreciate a committee of J Random JavaScript
Developers randomly dumping extra work into my product backlog because they
didn't like the cut of an API's jib, especially when these people have gone
absolutely out of their way to drive adoption in the first place.

To give a counter-example: .NET code I wrote in the mid-noughties whilst
working at Red Gate still runs today, substantially unmodified. Some of that
stuff is 11 or 12 years old. SQL Dependency Tracker is the most obvious
example, because the product hasn't changed much since 2006, except for
additions to support new object types in new versions of SQL Server. The fact
that new .NET versions haven't broken the product has obviously made it _much_
easier to support through the years.

~~~
gizmo686
That is the entire point of the major version. The fact is, developers
sometimes make breaking changes (sometimes for good reasons, sometimes for
bad), and we want a standard way of documenting that. If you don't make
breaking changes, than stay on 1.X.Y forever. If your project is only a year
old and already on version 10.0.0, you are probably doing something wrong; but
at least documenting it in your version numbers.

~~~
bartread
Certainly take your point, and maybe it's in part down to my background, where
a new major version generally includes some large chunk of new functionality
(regardless of whether or not there are breaking changes).

And really I suppose you don't ever _need_ to go beyond version 1.x.y. Window
Maker is quite a good example of this: latest version is 0.95.8 after 20 years
of development.

