LearnNewsExamplesServices
Frontmatter
id3311
titleStabilize and improve versioning for the package neo.mjs by introducing beta version directly from dev branch
stateClosed
labels
enhancementstale
assignees[]
createdAtJul 20, 2022, 11:36 AM
updatedAtSep 14, 2024, 4:26 AM
githubUrlhttps://github.com/neomjs/neo/issues/3311
authordavhm
commentsCount5
parentIssuenull
subIssues[]
subIssuesCompleted0
subIssuesTotal0
blockedBy[]
blocking[]
closedAtSep 14, 2024, 4:26 AM

Stabilize and improve versioning for the package neo.mjs by introducing beta version directly from dev branch

Closed v8.1.0 enhancementstale
davhm
davhm commented on Jul 20, 2022, 11:36 AM

Currently every small improvement on dev is merged into main to be published and installable by users of neo.

Disadvantages for developers:

  • It breaks semantic versioning:
    • New features are being added without raising the minor version number
    • New patch versions are published which might introduce breaking changes, which breaks stable projects using the package after an npm install
  • It introduces the risk of publishing unstable and untested changes as a main version. A user relying on neo for productive work installs a new version of the package (e.g. 4.0.98) to find out it is broken. They then have to find the version causing the breakage & manually downgrade the package while they wait for a fix. In summary: A very painful developer experience if you want a stable app using neo

Disadvantages for contributors:

  • Every small improvement has to be merged into main immediately to be testable elsewhere.
  • No way to easily consume and test experimental changes locally without breaking the stable version of the package

Proposed change

Instead, I propose to publish a beta version directly from dev branch, which adds for example the latest commit id into a published version, like `4.1.0-beta.3dc41d8a2'.

Then, using npm dist-tags. a version tag can be added (for example) as:

  • neo.mjs@beta or
  • neo.mjs@<next-minor-version>-beta

The dist-tag points to the latest published version, so that users can then explicitly `npm install neo.mjs@

Advantages:

  • Semantic versioning is respected, so that stable projects consuming neo won't get unstable versions on every npm install
  • Users who want to test/require the in-development features of neo which might not yet be stable can specifically explicitly npm install neo.mjs@rc and still get the latest changes to the package, without
davhm added the enhancement label on Jul 20, 2022, 11:36 AM
tobiu
tobiu Jul 20, 2022, 11:40 AM

David, this part: "New features are being added without raising the minor version number"

is actually not correct.

a merge from dev to main only happens in case there is a new minor version number, which will then get released into a new npm package version.

davhm
davhm Jul 20, 2022, 2:15 PM

This means the new patch versions are being released from the dev branch already, without any merging into main?

For example, setting default headers for XHR requests was added. This however didn't result in a minor version increase, but just a patch version.

Dinkh
Dinkh Jul 20, 2022, 4:59 PM

I would go with beta versions too. That way we can write version upgrade plans, so that users do not loose stability. Instead of having 20 minor versions, we this might be the next version incrementation:

next 4.0.71.123 next beta 4.0.72 next public 4.1.0

@github-actions - 2024-08-30T02:27:53Z

This issue is stale because it has been open for 90 days with no activity.

  • 2024-08-30T02:27:53Z @github-actions added the stale label

@github-actions - 2024-09-14T02:26:57Z

This issue was closed because it has been inactive for 14 days since being marked as stale.

  • 2024-09-14T02:26:58Z @github-actions closed this issue