mesa
mesa copied to clipboard
projectmesa
v1.0.0 Quartzsite release
Please review closed tickets currently associated with Quartzsite release. These will be used to build the history.
Also release to follow Quartzsite has been created - Safford.
Also - what version number do want to place on this?
1.0.0 instead of 0.10.0, because there is a breaking change with batch_run defaulting to 1 CPU.
I am under the impression that currently development is very active and so I would vote for 0.10.0., because I have the impression that there are a lot of moving parts right now and I would reserve 1.0.0 for a more stable version. But we should definitely have a discussion on when we are ready for 1.0.0. and hopefully achieve that soonish.
1.0.0 instead of 0.10.0, because there is a breaking change with
batch_rundefaulting to 1 CPU.
? I don't understand, could you clarify your logic here?
As per semantic versioning, every time you introduce breaking API changes, you bump the major version.
Given a version number MAJOR.MINOR.PATCH, increment the:
MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards compatible manner, and
PATCH version when you make backwards compatible bug fixes.
The batch_run defaulting to 1 CPU has a major impact on the tutorial simplification for Windows, and so can't be reverted easily if you want a release without breaking changes.
Alternative interpretation: https://0ver.org/. In this sense 0.10.0, is still a major release.
As per semantic versioning, every time you introduce breaking API changes, you bump the major version.
Semantic versioning is a great idea and the specification is a nice read. You should definitely read the whole document!
But there are several reasons why this doesnt require a push to 1.0.0. First of all we never stated we use semver. I think we definitely should, but there is currently no hard requirement to follow the spec (but again, we should). Next, a major version bump must happen when an incompatible API change happens. But batch_run changing its default argument is not one. The change is fully backwards compatible since it requires no code changes and it will produce the same outputs.
However, there have been some breaking API changes, e.g. https://github.com/projectmesa/mesa/pull/1333. There might be others. So the point remains valid. However, if you read Point 4 of the semver spec: With a major version zero, a public API should not be considered stable and anything may happen at any time.
Nice catch. I forgot the existence of #1333 (I thought I was missing a breaking change, but couldn't pinpoint it).
First of all we never stated we use semver. I think we definitely should ...
We should use semver right away, because people might use the ~= operator for the version constraint in their requirements.txt (see https://peps.python.org/pep-0440/#compatible-release), and doing a bump to 0.10.0 will upgrade their Mesa dependency unknowingly.
But batch_run changing its default argument is not one. The change is fully backwards compatible since it requires no code changes and it will produce the same outputs.
This is probably a nitpick. As a modeler, I'd be wondering why my batch_run suddenly runs much slower with a single process.
However, if you read Point 4 of the semver spec: With a major version zero, a public API should not be considered stable and anything may happen at any time.
IMO the API is pretty stable with small exceptions (the batch_run defaulting to 1 CPU, and #1333). Anything "unstable" you have seen so far, e.g. upgrading Bootstrap, does not affect the API. We do have simplified namespace import now, but this is in addition to the existing import style, and so, not a breaking change. We still BatchrunnerMP if people still want to use it.
This is probably a nitpick. As a modeler, I'd be wondering why my
batch_runsuddenly runs much slower with a single process.
I strongly disagree on this being a nitpick. The semver specification is specifically about API compatibility and this does not break API compatibility. On the contrary, the bootstrap upgrade is a breaking change, since users can implement custom visualization elements and rely on the exposed bootstrap version for that.
Anyway, I don't want to derail this discussion. Your original comment just made it sound like we somehow have to increase the version to 1.0.0 because of breaking changes. This is not the case. It might still be the right time for a 1.0.0. release, but breaking changes are not a valid reason. By definition of the semver spec, 0.x.y versions should not be considered stable and thus anything might happen without breaking semver compliance.
I would just like to say amazing job!
Quartzsite will consist of of 111 pulls and in the past two weeks we have had 1065 unique visitors and 412 unique clones!
That is super cool
The semver specification is specifically about API compatibility and this does not break API compatibility.
The default value of an argument being changed in a public function in https://github.com/projectmesa/mesa/blob/c2103830cd9054bdb5437a712e1add1e474daf95/mesa/batchrunner.py#L39. That's an API breaking change no matter how you dice it.
I have also stated my other reason to go 1.0.0, i.e. because of how people expect a version bump should happen in their requirements.txt when they do ~= 0.9.
After today's dev discussion and taking these comments into consideration -- we decided 1.0 So, if this is 1.0 -- where do these tickets go? https://github.com/projectmesa/mesa/milestone/30 Untag and kill the milestone?
@rht how should i document this PR - https://github.com/projectmesa/mesa/pull/1357? It still exists. I feel like it should be captured in some way in the history.
That PR is merged into projectmesa:base_ci_cache_experiment, not the main branch, and so can be ignored.
Great News! So now we officially adopt semantic versioning? Then we should document this somewhere, either in the readme or the contributing file
v1.0.0 has been released, so I am going to close this ticket -- https://pypi.org/project/Mesa/