Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make a 0.6.0 release #219

Closed
Freso opened this issue Jan 27, 2018 · 9 comments
Closed

Make a 0.6.0 release #219

Freso opened this issue Jan 27, 2018 · 9 comments
Labels
Support Questions that needs answering with no code changes needed or that only require a one time change

Comments

@Freso
Copy link
Member

Freso commented Jan 27, 2018

There have been a number of significant patches/PRs merged since v0.5.1. whipper no longer uses any morituri namespace, so the two could be installed side-by-side, it now uses libcdio-paranoia instead of cdparanoia, AccurateRip v2 support has been added, etc., etc.

I know we want 1.0.0 to be released ASAP, but I think making a 0.6.0 release now would be good to let packagers start making packages with the new dependencies (libcdio-paranoia and python(2)-requests) and to get the current state-of-the-code into more users' hands for wider testing, to possibly find any/more regressions before a "final" 1.0.0 release is made.

I think it would be fine to just set the 0.6.0 release at the HEAD of the current master branch, this is still a pre-release release.

@MerlijnWajer
Copy link
Collaborator

In addition, I would propose that odd numbered releases are perhaps considered testing/beta releases, and even numbers ones stables ones? But then 0.7 would make more sense.. :)

@Freso
Copy link
Member Author

Freso commented Jan 27, 2018

I disagree with that. :) Let's stick to semver and use -beta etc. postfixes for testing releases. (Note that anything <1.0.0 is a testing/unstable release in semver: «4. Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.»)

@JoeLametta
Copy link
Collaborator

Good idea.
I've found the following changes to be backward incompatible, am I missing any other?

@JoeLametta
Copy link
Collaborator

Let's stick to semver

We don't have a defined API: how do we deal with this?

@MerlijnWajer
Copy link
Collaborator

We do have an API, it's just internal. We don't really have to worry about this until we support 'library usage', as I have hacked morituri to do.

@Freso
Copy link
Member Author

Freso commented Jan 30, 2018

We also have an external API: whipper <global arguments> <command> <command arguments> + the configuration file.

Altering the commands/arguments or the configuration file in a non-backwards compatible way would require a new major version according to SemVer.

Edit: Also, some alterations in some outputs may warrant being called "breaking API", e.g., if we change the .log output format.

@Freso
Copy link
Member Author

Freso commented Feb 2, 2018

I just looked over v0.5.1...master and I don't see any backwards incompatible changes other than the ones @JoeLametta mentioned in his comment before.

@JoeLametta JoeLametta added the idea label Feb 2, 2018
@JoeLametta
Copy link
Collaborator

Will tag it later today.

@JoeLametta
Copy link
Collaborator

Done: v0.6.0.

😉

@JoeLametta JoeLametta added Support Questions that needs answering with no code changes needed or that only require a one time change Accepted Accepted issue on our roadmap and removed idea Accepted Accepted issue on our roadmap labels Nov 12, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Support Questions that needs answering with no code changes needed or that only require a one time change
Projects
None yet
Development

No branches or pull requests

3 participants