Release, Tags, NEWS?

[ArchangeGabriel]

Hi,

I’ve seen that the setup.py file now reports 0.3. Do you consider this as a release?

If so, you should update the NEWS file and some other things like that, tag the version, and release it in the corresponding tab. ;)

Else, avoid bumping that number until release, because sane tools building from git (see the ArchLinux AUR PKGBUILD for instance) use the tag as base version number, and will report v0.2.3 currently, while they have apparently been a 0.2.4 and now 0.3. ;)

Other than that, keep doing this great work! :)

[RecursiveForest]

The version number got bumped 'by accident' by a PR I made being accepted without changing the number on merge. 0.3.0 is still a WIP but I believe pending one more PR is going to be released.

Thanks for calling us out on this, this is also a good reminder to set the tag & provide a release tarball (especially so more of our users are off -git, because the test situation means we sometimes break things).

[JoeLametta]

The version number got bumped 'by accident' by a PR I made being accepted without changing the number on merge. 0.3.0 is still a WIP but I believe pending one more PR is going to be released.

I remember that one.
Maybe, after reaching milestone 1, we can reset the version number to 1.0.0. The current way of handling updates (and version numbers) isn't really meaningful. Don't know if it's overkill for a project like this but Semantic Versioning seems a reasonable choice.

[RecursiveForest]

I like Semantic Versioning.

[JoeLametta]

@neitsab
Tagged releases v0.3.0 & v0.4.0 (current).

v0.4.0 includes the following notable change (it is mentioned in the README):

Whipper is now invoked by its name (whipper) instead of rip

[RecursiveForest]

#71 in combination with the releases Joe mentioned above should resolve this.

[neitsab]

@JoeLametta Thanks for the heads up!

Does the substitution of whipper to rip means the two programs can be installed alongside? I'm just asking because for now we "conflict" them in the AUR package.

[neitsab]

Second question: now that you're doing versioned releases, I'm thinking of creating a non-git package for users who prefer stability/non-development versions. Despite the "pre-release" status, do you consider the tagged versions stable?

[JoeLametta]

Does the substitution of whipper to rip means the two programs can be installed alongside? I'm just asking because for now we "conflict" them in the AUR package.

Didn't check: probably yes (I'm going to test and let you know the outcome).

Second question: now that you're doing versioned releases, I'm thinking of creating a non-git package for users who prefer stability/non-development versions. Despite the "pre-release" status, do you consider the tagged versions stable?

For the moment being I think it's better waiting (not because tagged release are really unstable: the reason is that whipper is still under heavy development). Maybe it's better to do this after Milestone 1 has been reached.

[JoeLametta]

Does the substitution of whipper to rip means the two programs can be installed alongside? I'm just asking because for now we "conflict" them in the AUR package.

Didn't check: probably yes (I'm going to test and let you know the outcome).

Yeah seems so.

[ArchangeGabriel]

Will Milestone 1 get ride of remaining submodules? That would be very nice in order to build a stable package.

[JoeLametta]

Will Milestone 1 get ride of remaining submodules? That would be very nice in order to build a stable package.

No, that's scheduled for milestone 2 (more information here).

[tobbez]

Does the substitution of whipper to rip means the two programs can be installed alongside? I'm just asking because for now we "conflict" them in the AUR package.

Contrary to previous comments, whipper and morituri are not yet installable alongside. The two packages still use the same Python module name (morituri).

This means that installing one after the other (using a method that doesn't check for file conflicts) will clobber the previous installation, leaving the code in an undefined state. If both programs still work after that, it'd be by pure luck (and calling the program installed first would be to call the one installed second, but with another name).

Created #100 to track the required change.

[JoeLametta]

This issue should now be resolved.