5 ms·

Version numbers dont mean anything unless you make clear you are using semver. does starting from 0.0.1 or 1.0.0 change anything? not really

meiraleal 2y ago
1.0 being the first stable release of a project is an obvious convention older than semver
- Woshiwuja 2y ago
  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.
jamietanna 2y ago
True! But there are a number of ecosystems where it's implied that you use SemVer i.e. Go in https://go.dev/doc/modules/version-numbers https://go.dev/doc/modules/version-numbers
- Woshiwuja 2y ago
  you are right, i was talking about the times it isnt implied or forced onto you. Notably also Go does that if you dont specify the version, in the Pseudo Version Number section, which is a more sane way to version stuff in my opinion

meiraleal 2y ago

1.0 being the first stable release of a project is an obvious convention older than semver

Woshiwuja 2y ago
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.

jamietanna 2y ago

True! But there are a number of ecosystems where it's implied that you use SemVer i.e. Go in https://go.dev/doc/modules/version-numbers https://go.dev/doc/modules/version-numbers

Woshiwuja 2y ago
you are right, i was talking about the times it isnt implied or forced onto you. Notably also Go does that if you dont specify the version, in the Pseudo Version Number section, which is a more sane way to version stuff in my opinion