# New automerge requirement: Release notes required for breaking package releases

**URL:** https://discourse.julialang.org/t/new-automerge-requirement-release-notes-required-for-breaking-package-releases/123955
**Category:** Package Announcements
**Tags:** general-registry, registryci
**Created:** [December 18, 2024, 10:41am UTC](https://discourse.julialang.org/t/new-automerge-requirement-release-notes-required-for-breaking-package-releases/123955 "2024-12-18T10:41:37Z")
**Posts on this page:** 1
**Showing post:** 8

<div class="post-metadata">

### Author: ![ericphanson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ericphanson/32/215186_2.png) [@ericphanson](https://discourse.julialang.org/u/ericphanson)
#### Post date: [December 20, 2024, 11:02am UTC](https://discourse.julialang.org/t/new-automerge-requirement-release-notes-required-for-breaking-package-releases/123955/8 "2024-12-20T11:02:49Z")

</div>

I think with the current Julia ecosystem, there are a bunch of heavily used, infrequently breaking packages that are nonetheless pre-v1. In fact, here’s 100 packages that are pre-v1.0 but have added an average of \> 140 new users per day for the duration we have [package statistics](https://discourse.julialang.org/t/announcing-package-download-stats/69073) collected:

> JSON, DataStructures, LogExpFunctions, MacroTools, DocStringExtensions, StatsBase, TranscodingStreams, IrrationalConstants, CodecZlib, InverseFunctions, ColorTypes, ChangesOfVariables, Distributions, GR, Colors, ForwardDiff, Latexify, Formatting, FixedPointNumbers, PDMats, RecipesPipeline, ColorVectorSpace, Contour, IniFile, StructArrays, FFMPEG, Measures, CommonSubexpressions, Rmath, Distances, UnicodeFun, GPUArraysCore, ExprTools, TensorCore, Parameters, CSV, FilePathsBase, HypergeometricFunctions, Unzip, Calculus, BitFlags, Interpolations, DualNumbers, GeometryBasics, Inflate, Ratios, CEnum, IfElse, SimpleTraits, AbstractTrees, LoopVectorization, TimerOutputs, ArrayInterfaceCore, StringManipulation, Observables, ArnoldiMethod, VectorizationBase, JLFzf, IntervalSets, DensityInterface, SLEEFPirates, CPUSummary, ZygoteRules, CommonSolve, LayoutPointers, JLD2, NearestNeighbors, HostCPUFeatures, PolyesterWeave, ThreadingUtilities, CloseOpenIntervals, KernelDensity, BitTwiddlingConvenienceFunctions, JuliaInterpreter, PositiveFactorizations, MappedArrays, SymbolicIndexingInterface, Widgets, ManualMemory, Clustering, CodecBzip2, Mocking, ExceptionUnwrapping, SIMDTypes, Tricks, ImageCore, Extents, CategoricalArrays, PaddedViews, CompositionsBase, CpuId, StrideArraysCore, Polyester, TiffImages, Transducers, PreallocationTools, PNGFiles, NNlib, RecursiveFactorization, Lazy

I think a breaking change to almost any of these would be fairly disruptive and users would benefit from release notes that indicate what the breaking changes were. There are 7k more pre-v1.0 packages as well.

> **code**
>
> ```julia
> using CSV, DataFrames, RegistryInstances, UUIDs, Dates
> 
> registry = only(filter(reachable_registries()) do reg
> reg.name == "General"
> end)
> 
> # Download and uncompress:
> # https://julialang-logs.s3.amazonaws.com/public_outputs/current/package_requests.csv.gz
> requests = CSV.read(expanduser("~/Downloads/package_requests.csv"), DataFrame)
> subset!(requests, :client_type => ByRow(==("user")), :status => ByRow(==(200)); skipmissing=true)
> 
> function lookup_pkg(uuid)
> pkg = get(registry.pkgs, UUID(uuid), nothing)
> pkg === nothing && return (; name=missing, latest_version=missing)
> name = pkg.name
> latest_version = maximum(keys(registry_info(pkg).version_info))
> return (; name, latest_version)
> end
> 
> versions = unique(select(requests, :package_uuid))
> transform!(versions, :package_uuid => ByRow(lookup_pkg) => AsTable)
> 
> leftjoin!(requests, versions; on=:package_uuid)
> disallowmissing!(requests, [:name, :latest_version])
> subset!(requests, :name => ByRow(!endswith("jll")))
> 
> counts = select(requests, :name, :latest_version, :request_addrs, :date_min, :date_max)
> transform!(counts, [:request_addrs, :date_min, :date_max] => ByRow() do n, min, max
> n / Dates.value(Day(max - min))
> end => :request_addrs_per_day)
> subset!(counts, [:date_min, :date_max] => ByRow(!=))
> sort!(counts, :request_addrs_per_day; rev=true)
> pre_v1 = subset(counts, :latest_version => ByRow(<(v"1")))
> 
> println(join(first(pre_v1.name, 100), ", "))
> 
> ```

I agree more packages should move to v1+, but I don’t think adding additional restrictions for v1+ helps that. If anything, it makes an incentive _not_ to move to v1, since then there’s additional rules to follow.

That being said, I’m not totally opposed to relaxing this rule. But my biggest concern with it is burden to package developers, not principles of semver.

What are the main issues with requiring release notes? It is a new workflow to some, that’s true, but JuliaRegistrator has been prompting for release notes for years, and JuliaHub has similarly had a textbox for it for a long time. Is it coming up with something to say? Or a mismatch between how folks are already doing release notes in some other way?

---

_[View the full topic](https://discourse.julialang.org/t/new-automerge-requirement-release-notes-required-for-breaking-package-releases/123955)._