Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
GHC
GHC
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 4,273
    • Issues 4,273
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge Requests 413
    • Merge Requests 413
  • Requirements
    • Requirements
    • List
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Security & Compliance
    • Security & Compliance
    • Dependency List
    • License Compliance
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Code Review
    • Insights
    • Issue
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • Glasgow Haskell Compiler
  • GHCGHC
  • Wiki
    • Commentary
    • Libraries
  • eager version bump

Last edited by Tobias Dammers Mar 29, 2019
Page history New page

eager version bump

Eager Version Bumping Strategy

Versioning of GHC core/boot libraries adheres to Haskell's Package Versioning Policy whose scope is considered to apply to released artifacts (and therefore doesn't prescribe when to actually perform version increments during development)

However, in the spirit of continuous integration, GHC releases snapshot artifacts, and therefore it becomes important for early testers/evaluators/package-authors to be presented with accurate PVP-adhering versioning, especially for those who want adapt to upcoming API changes in new major GHC releases early (rather than being hit suddenly by a disruptive version-bump-wave occurring at GHC release time).

So while the usual scheme is to update a package version in the VCS right before a release (and reviewing at that point whether a patchlevel, minor or major version bump is mandated by the PVP), for GHC bundled core/boot packages, the eager version bumping scheme is preferred, which basically means:

The Cabal version gets patchlevel/minor/major version bumped as soon as it becomes evident that a patchlevel/minor/major version increment (relative to the previous released version) is mandated by the PVP

This becomes particularly easy when also maintaining a changelog file during development highlighting the changes for releases, as then one easily keeps track of the last released version, as well as becoming aware more easily of minor/major version increment-worthy API changes.

Clone repository

GHC Home
GHC User's Guide

Joining In

Newcomers info
Mailing Lists & IRC
The GHC Team

Documentation

GHC Status Info
Working conventions
Building Guide
Debugging
Commentary

Wiki

Title Index
Recent Changes