1.0 Milestones

[marcharper]

Re #551 , I think once #552 is in place I think we are close to being ready for a 1.0 release. If there's anything you want to suggest as a milestone for 1.0, please add it to the comments here.

[drvinceknight]

👍

[meatballs]

Are there any egregious gaps in the strategies? For example, are we very close to being able to reproduce a previous tournament but only missing one or two strategies?

[marcharper]

Not that I am aware of, unless some documentation emerges from the aether on the early axelrod tournaments.

[marcharper]

I'd like to see #538 in as well before 1.0.

[drvinceknight]

#580 should go in before 1.0 as well. It has some backwards compatibility implications that from 1.0 we should aim to minimise (if I understand correctly).

[drvinceknight]

So I think we're ok to go for 1.0.0.

Would the following make sense (making sure I understand), for x.y.z:

• An increment in z would be bug fixes and things in the background (for example the increased efficiency @marcharper just put in)
• An increment in y would be new strategies, new user facing functionality (the inclusion of the moran process for example)
• An increment in x would be something that is not backwards compatible (say we all of a sudden decide that the play method no longer returns a results set, or new non optional parameters are needed for some class that's already in the library).

Just want to make sure we're all on the same page because if the above is right, the idea would be that the current user facing things would not change for a while at least. The hope being that we are relatively stable and don't increment x too often...

[marcharper]

I think something like this is fine. The bump to 1.0 shows that we believe the library to mature and stable enough for reliable usage, and I'm not so concerned when we choose to bump y. Frequent z releases are fine IMO, we can release for critical bug fixes and whenever we accumulate enough commits to tag and release otherwise.

An official change-log going forward may be a good idea.

[drvinceknight]

A proper change log would be good. We've got the CHANGES.txt file that I usually update by looking through the diffs from one version to the next. But I don't think I do a good job at that.

What would a better change log look like? I've seen some projects for which they appear in the docs, is that a good way to go? Would we ask for them to be added to the change log during a PR?

[marcharper]

Just more detail than the current changes file would be good. It's not necessarily a hard requirement for PRs IMO, it's just nice to know more about what's in a new version. In the docs would be fine, or just in the repository.

[drvinceknight]

Ok: so sounds like what we're doing now but 'better' (I completely agree the job is being done pretty poorly right now). I can try and just do better (I really should), and/or everyone can always PR in to the CHANGES.txt (using github's diff page it's easy enough to see differences between tags: here's the current status v0.0.31...master

On https://github.com/Axelrod-Python/Axelrod/blob/master/CHANGES.txt we could also have a line like:

v0.0.30, 2016-04-08 -- Reading and writing tournaments to file, better pickling.
v0.0.31, 2016-04-18 -- Moran processes, better caching architecture and match generator
master, open -- Add ongoing things here

Does that sound good?

[drvinceknight]

Closed by 7e19f65