search

s4hri / pykron

Other
0 stars 2 forks source link

What about versioning? #9

Open ddetommaso opened 3 years ago

ddetommaso commented 3 years ago

We need to define a standard versioning system for this project. We want:

  1. Versioning system
  2. Changelog

In the following we will discuss possible solutions to address this issue.

adamlukomski commented 3 years ago

Proposition:

API changelog and releases

The default versioning system is 1.x, where changes in the major number indicates that the API has been modified significantly, and the code examples or tests needed to be changed drastically to reflect that. Minor version changes usually add functionality and retain backwards compatibility in the same major number (mostly).

API changelog will be kept in doc/release/release_0.13.rst as a part of documentation

ddetommaso commented 3 years ago

I think the semantic versioning it's a bit more complete and standard

Given a version number MAJOR.MINOR.PATCH, increment the:

  1. MAJOR version when you make incompatible API changes,
  2. MINOR version when you add functionality in a backwards compatible manner, and
  3. PATCH version when you make backwards compatible bug fixes.

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

https://semver.org/

adamlukomski commented 3 years ago

updated in documentation to MAJOR.MINOR.PATCH

ddetommaso commented 3 years ago

@adamlukomski what about having an automatic generation of MAJOR.MINOR.PATCH format based on github commits?

For example:

Current version is 0.14.0

Let's suppose that I find a bug and I open an issue on github. I create a separate branch 'my_fix' then I commit the fix mentioning this issue in the comments and then I create a PR. Is there a method to automatize the creation of a new release tag 0.14.1 after the merge in the master?

ddetommaso commented 3 years ago

Maybe it worth to check out this https://github.com/bumped/bumped

ddetommaso commented 3 years ago

Another nice solution might be using dockers!

adamlukomski commented 3 years ago

Docker image: all tools (bumped, libs for visualization) downloaded in the Dockerfile, pykron repository cloned, requirements from "requirements/default.txt" downloaded scripts to automatically fetch new commits from respective repositories scripts to push changes / prepare releases

so the goal would be to have a one-click solution to instantly pull a docker image from Docke Hub, update the repositories, make changes and a pull request

ddetommaso commented 3 years ago

PROPOSAL: Using GitHub actions with semantic-release

https://github.com/semantic-release/semantic-release/blob/master/docs/recipes/github-actions.md