Closed merkys closed 2 years ago
Hello Merkus! Thank you very much for your feedback. I understand your confusion. In general all projects are going like you said. But my project is different. From the very beginning I am the only one developer and my aim is to continuously deliver the best product to user. Therefore the last version (last commit) is the best one (I do my best for this). Can your explain me your project and aims to find a best possible solution for you?
Hi @orex, thanks a lot for prompt response. I understand the appeal of your release approach and I am aware of other pieces of software that use the same approach. In principle Git commit hashes sometimes are used instead of a version number. However, since they are non-sequential, given two Git commit hashes it is quite difficult to tell which one came before the other.
I am interested in reproducible science. Identifiers for immutable source code are very important to be able to replicate scientific computation results. I do understand, though, that supercell output is non-deterministic due to randomization, but it may happen that the randomization method changes between subsequent commits, for example.
So my question is whether v2.0 does point to an immutable source code, or is it a name of some development branch. Even in that case it is common to tag the first commit in the branch with v2.0 and refer to subsequent commits as "v2.0+123" where 123 is the number of commits past the initial "v2.0" tag.
Hello @merkys!
I got your point. I tagged the latest release for my program. You can use it as a reference. For the future, I'll tag all the changes in source code with such tags. Changes in docs and examples, which embedded to the master branch, will be not released. Talking about reproducibility of the results, I put much attention to this. You can be sure that even random structures will be the same with the same input seed (see man supercell
) within at least major version (v2.x). The main source of nondeterministic can come from floating point operations, mostly from electrostatic calculations. It depend on CPU, compiler and compile options. Don't use -ffast-math
and specify exact CPU target to improve reproducibility.
Reference binaries for all tags are available here: https://github.com/orex/supercell/tree/gh-pages/deploy_artifacts
I plan to do some minor improvement until the end of the year. I'll tag the release as v2.0.2
Best, Kirill.
Thanks a lot for agreeing to tag releases! It is great to know the way to set the seed for randomization as well - this helps reproducible research a lot. I am closing this issue as resolved now.
I am interested in building supercell from the source. However, I cannot find a way to obtain the source pertaining to supercell v2.0 as git HEAD may already contain commits on top of v2.0. In Git, usually Git tags are used to mark releases as they point to a specific commit (immutable source, in theory). It would be very nice if tags were added for stable releases of supercell, at least for v2.0.