Allow manifest to constrain releases to build

[SeanTAllen]

By default, a manifest file will try to build every possible release available. For various reasons, we might not want to build every version:

• The release doesn't build with the current ponyc compiler
• The release doesn't build with the current ponyc compiler and it predates whenever we allow for information to be included for what ponyc compiler is required thereby making it impossible to build.
• The author decides that some versions shouldn't be included.
• and more I'm sure

As a first pass at this, I think the manifest should support two additional fields:

• only: an array of versions to build. no other versions will be built.
• except: an array of versions to skip building. all versions except the listed will be built.

It should be considered an error to use both only and except in the same manifest. An error should be thrown if that is the case. Ideally this would eventually be part of a CI validation step.

[jemc]

Maybe a regular expression pattern of which versions to build?

[jemc]

Actually, I just noticed in the other tickets that you've suggested constraining version names to the x.x.x format. With that restriction in place, we could do something smarter than a regular expression - like, for example, a condition-based range, such as:

{
  "only": [">=1.0.0", "<2.0.0"]
}

[SeanTAllen]

@jemc i like.

[StephenStrickland]

Much along the lines of @jemc, what about restricting package versioning to follow Semantic Versioning? Additionally, we could adopt how NPM handles constraining versions: https://docs.npmjs.com/about-semantic-versioning

[SeanTAllen]

I don't think semantic versioning as defined is particularly helpful.

What is a "breaking change"?

Certainly an API changing in a way that requires manual intervention to fix is. What about changing the behavior of a method in a way that invalidates previously working code?

Personally I prefer x.y (or 0.x.y for 'pre-1.0' packages)

where x is "this will require manual intervention" and y is "this will not require manual intervention"

I think everything else that semantic versioning promises is... I don't think its particularly meaningful..

[StephenStrickland]

To a certain extent, a "breaking change" is subjective. But what versioning system that involves humans isn't? SemVer is meant to be machine readable and at the same time convey an approximation of the changes to humans.

Since SemVer is an attempt to simplify reasoning about package upgrades and dependency management, a "breaking change" is considered one that breaks the current public API. SemVer isn't trying to solve the problem of behavior. I believe that responsibility lies with both the producer and the consumer of the package. For the producer to manage and monitor changing behavior between releases and the consumer for testing incoming package changes and alterations in desired application behavior.

I was suggesting SemVer since it has been adopted by other communities, and for some, easy to understand and work with.

If we're looking to build a system that self monitors the behavior of a package and automates Major.Minor.Path versioning, we could follow how evan built the package manager for the Elm programming language. I don't think the Elm way is perfect, but with Pony's powerful type system it'd be a fun investigation. Another way of detecting changes would be to implement Dependent Types like Idris where you could basically let the language/compiler do all the work for you. I know at one point a few years back someone was working on Value-Dependent types in Pony, don't know if that would help or be related to the issue at hand since I haven't looked into that work at all.

[EpicEric]

The way I see it, the implementation of SemVer for API compatibility (i.e. making sure minor-patch changes do not break existing API or behavior) is out-of-scope of this discussion, since it's more of a matter of the maintainer's desire to follow the specification or not. Deciding whether to follow this or some other specification would be a later issue. (as a side-note whenever the new issue is created, my suggestion would be a superset of SemVer, allowing any number of leading integers; [">=2.7.2", "<3.5"] would be valid).

What we can use from SemVer, in regards to this issue, is its clearly defined precendence rules, which falls more in-line with @jemc's suggestion.

[jemc]

@StephenStrickland - out of curiosity, can you share more info about the specific feature of Idris that you're thinking of?

[StephenStrickland]

@jemc not necessarily Idris specifically, but dependent types in general that can be found in coq, *f,... Idris does provide tooling that guesses and autogenerates code based upon declared dependent types. I wonder if you could build a similar system to formally verify third party packages not only at the API level but behaviorally by leveraging dependent types. Just a random idea I had that might not apply to the Pony community.

[jemc]

I was just asking for more detail because I didn't see how dependent types should fit into versioning. It sounds like it could be a cool idea, but as of right now I don't understand in enough detail to properly evaluate it.

[SeanTAllen]

This is no longer applicable given the change in main.actor architecture that has been done.

See https://gist.github.com/SeanTAllen/1ecefb51c606c1a5b5b278b89aa49f4e