8 ms·

Was it ever a standard? not so obvious

• throwaway74256 2y ago
  Individual projects and companies often had standards that they communicated to their users. Some treated it as a progress indicator where 1.0 was considered "done" according to the planned features, but each 0.X release was ready for production. Others would not recommend production use until 1.0. In any case, most users expected 1.0 to be ready for production and stable. As a work-around for tools that don't support 0.x releases, I guess they could mark it as 1.0-UNSTABLE or something, but I think most would assume that a 1.0 release implies a more stable API than a 0.1. This can lead to misunderstandings and unnecessary friction. The tool mentioned in the article seems to enforce an opinionated view of development that results in partial support for semantic versioning. The developers of this library has a certain view of how semantic versioning should work, which they are free to have of course. We can't force them to implement the full standard, but it is still valid to ask questions. The semantic-release README claims "strictly following the Semantic Versioning specification and communicating the impact of changes to consumers.". I guess it is technically correct as they support a partial implementation, but it is not what I expect when reading this statement. While the features they support are implemented according to the standard, it's not complete. I also think that the "communicating the impact of changes" part can be confusing when an upgrade from 1.0.0-alpha to 1.1.0-alpha allows major API breakage just because it uses a pre-release naming syntax.