Release a v1.0.0
See original GitHub issueIt seems that this is quite stable. As such, it would be really nice with a proper 1.0.0 release, so for future releases, it will be possible to discern from the versioning whether it contains new features (minor version bump), or any breaking changes (major version bump). In the 0.x.x
range, the minor part can signal either of these.
Issue Analytics
- State:
- Created 3 years ago
- Comments:7 (4 by maintainers)
Top Results From Across the Web
Semantic Versioning 1.0.0
A pre-release version number MAY be denoted by appending an arbitrary string immediately following the patch version and a dash. The string MUST...
Read more >Document the start version (v1.0.0 or v0.1.0) #268 - GitHub
The simplest thing to do is start your initial development release at 0.1.0 and then increment the minor version for each subsequent release....
Read more >v1.0.0 — Go for a better versioning mechanism | Nerd For Tech
Once the version has been released, the content should not be modified. Any modification must be accompanied by a new version. Pre-releases can ......
Read more >Getting software version numbers right. v1.0.0.1 - Stack Overflow
I'm starting to like the Year.Release[.Build] convention that some apps (e.g. Perforce) use. Basically it just says the year in which you ...
Read more >Release v1.0.0.0 - Elastica
Elastica v1.0.0.0 download. This release is compatible with elasticsearch 1.0.0. There is a larger list of breaking changes in this release ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
A while back I did a revamp of papi (the HTTP client this library uses) to use a more modern javascript style (await, const, classes, etc…) and I’ve been meaning to update this library to follow those same conventions. I was hoping to get that in before a 1.x release (it should be almost completely backwards compatible for the vast majority of users).
I just haven’t prioritized it. If I don’t get to it before the end of the year I’ll just release a 1.x branch.
I know it doesn’t help with tooling, but you can assume all 0.x releases will be backwards compatible until I release 1.0.0.
A side note, I was considering removing some of the client side validation so people wouldn’t need to wait on this library to explicitly support new arguments (maybe with some typescript definitions for documentation).
I don’t think there is a good reason not to just release a 1.x version of what’s in main. I’ll try to get that done this weekend.