Major change to package, but not the interface

Learn
1

I have a library which parses via RegEx. The RegEx has been updated, and could be a breaking change for a user. However Elm diff considers this to be patch. I think it should be a major change and communicate this via the version number.

Is there a way to force publish a major version change?

6 Likes
2

One way I have done this in the past is to add a dummy function to the public API e.g. isVersion1 = True. Then publish a minor version.

Then remove that or change it. At that point Elm will force me to publish a major.

I would like to know if there is a better way too.

6 Likes
3

Make sure you don’t add the breaking changes in the minor release

4

Don’t you specify the library version in elm.json? What is preventing you from updating the major version?

1 Like
5

I have manually adjusted the elm.json to be an 8.0 version (elm bump wants a 7.0.1). On publish Elm checks the versions, the output below.

  âś— Version 8.0.0 is not correct!

-- INVALID VERSION ---------------------------------------------------- elm.json

Your elm.json says the next version should be 8.0.0, indicating a MAJOR change
to the public API. This does not match the API diff given by:

    elm diff 7.0.0
6

Well that’s obnoxious. It sounds like Sebastian’s workaround will work for you. May I ask what the package is?

7

If you have a breaking change that isn’t an API change then I recommend making it an API change. This will solve your releasing problem while also allowing the compiler to help consumers of the package identify the breakage when they upgrade.

5 Likes
8

Without sufficient context none of us can say with certainty that “making it an API change” is sensible.

Here’s another example:

1 Like
9

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.