[opam-devel] current opam-repository policy : who can modify a package description
sheets at alum.mit.edu
Mon Feb 22 16:54:03 GMT 2016
On Mon, Feb 22, 2016 at 4:39 PM, Hannes Mehnert <hannes at mehnert.org> wrote:
> On 02/22/16 05:31 PM, Anil Madhavapeddy wrote:
>> Interesting idea -- so this would mean that OPAM has to remap
>> upstream versions into something that is a semantic version.
>> Does Elm eliminate this by mandating that libraries should
>> "natively" all be semantically versioned? We can't do this in
>> OCaml today since there are too many upstream packages with
>> their own versioning notions.
> Elm seems to check whether the API is compatible, and if not, only
> accepts a release if major is bumped:
> What does "own versioning notions" mean? I'd appreciate if the
> community would enforce (by peer pressure and adequate tooling) semantic
> versioning for the main opam-repository.
I agree that semantic versioning would be nice; however, semantic
versioning can never be solely relied upon.
For example, people make mistakes when assigning semantic version
numbers. Sometimes, changes that do break
compatibility are not surfaced at the signature level. A fallback
constraint method is required.
Additionally, I don't think any of the recent suggestions of
*enforcement* of behavior is wise. I'm of the opinion that, as
long as the package builds, has a bare minimum of metadata, a
reasonable name, and isn't harmful to users,
developers should be free to see their work published in
ocaml/opam-repository. We should absolutely adopt tooling
and social conventions to encourage positive behavior. I don't see any
benefit to exclusion due to versioning schemes,
lack of home pages, lack of examples, lack of documentation, and other
violated best practices.
More information about the opam-devel