Skip to content
This repository was archived by the owner on Mar 5, 2025. It is now read-only.
This repository was archived by the owner on Mar 5, 2025. It is now read-only.

Please don't inaccurately call 1.0 a "stable release" #2961

@wbt

Description

@wbt

Issue

As noted here:

Even the decision to just say "we're going to call beta37 the 1.0 stable release, despite all the good reasons why we've not considered it a stable release and despite all the important issues in it we've been finding and fixing over more than the past half year" seems like a somewhat arbitrary marketing-driven versioning decision and probably a bit of a lie on the "stable release" language which seems more likely meant to satisfy some VC or manager or PR purpose than to necessarily have the appropriate technical backing. (To me, changing to 1.0.0 could just be used to signify a breaking change; it doesn't have to be conflated with completion of a major milestone or even stability in the release, as seems to be conflated in Web3. Hyperledger Fabric put their first LTS release at whatever version number they were at when they thought they were ready, specifically 1.4).

And here:

(@wbt wrote:) I'm not convinced this project is ready for a "stable release" label/claim. I am in favor of steps back toward semantic versioning and having some base version that can be patched/modified to resolve outstanding issues alongside appropriate bumps in the semver number depending on what gets changed, as things get changed, without burying @nivida or anybody else under a mountain of outstanding action items that all have to get changed at once before any new useful developments can be released.

(@nivida replied): The missing announcement will explain this closer and any further or required questions can be asked in the publicly accessible EJC discord or with an issue here on GitHub.

This is that issue on GitHub, for focused discussion.

Calling the pending release 1.x seems appropriate based on there being major breaking changes from any 0.x version. Calling it stable just does not seem appropriate, seeing how unstable that code has been.

Why must "stable release" coincide with the breaking-changes version bump to 1.x? There does not appear to be any good technical reason for it, though there may be hidden other reasons that @nivida has so far consistently refused to elaborate on.

This issue proposes NOT calling the outcome of this PR a "stable" release. It's not really stable and there are good reasons why it was not put out as a stable release several months ago. Just call it the version number it's at (1.0 or 1.2 seeming most likely candidates) and continue patching/modifying that version with appropriate bumps in semver depending on what actually is changing. If/when the software reaches stability, have a discussion and make an announcement then.

The publicly available evidence is that the current version is not "stable" and by simply waiting for "the missing announcement" it'll be too late and damage will have been done by then. If there are good reasons to call it "stable," let's have that discussion here, before just putting it out there as an assertion of fact reached by one person's opinion or a small group's closed-door discussion.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions