search

SciRuby / daru

Data Analysis in RUby
BSD 2-Clause "Simplified" License
1.03k stars 139 forks source link

Design new daru release policy #411

Closed v0dro closed 6 years ago

v0dro commented 6 years ago

A formal 'release policy' will concretely state the rules and regulations that our community will follow when releasing new versions of daru and its plugins. It will clearly state the version numbers that permit breaking changes and when will user code require an overhaul due to version updates.

parthm commented 6 years ago

Perhaps the release policy could also consider having some sort of a pre-release (RC?) for a week or two before the final. This would allow some of the active Daru users to try Daru on their apps and report any issues found before any final release. Case in point would be #386 (min/max break) which is serious enough to prevent an upgrade to 0.1.6. Eagerly waiting for 0.1.6.1 (0.1.7?) :yum:

baarkerlounger commented 6 years ago

I would suggest we adopt this as our release policy http://semver.org/ from now on for versioning (Next new feature would be 0.2.0, next bug fix would be 0.1.7, big code cleanup can become 1.0.0 if it's decided API has changed and/or is being considered the first really stable release).

I would suggest we try to do releases more often also (happy to do this but think I would need elevated Repo permissions). Ideally at least patch release after every bug fix that's tagged as a major bug in the issue tracker.

I like @parthm idea of a pre-release. I would suggest that not apply to patch releases (in order to get bug fixes out as quickly as possible) but possibly apply to all feature releases and certainly to all major (breaking change) releases.

If people are generally in agreement I can create some documentation for this. Otherwise let me know other ideas.

zverok commented 6 years ago

@baarkerlounger sounds pretty reasonable for me :+1:

baarkerlounger commented 6 years ago

Can this be closed given the above is merged?