The release script does not handle versions properly

For example it has increased bob.extension from 2.4.5 to 3.4.5 where it should have been 3.0.0

I haven't checked other packages but I imagine this is the case elsewhere.

• The tag changelogs on gitlab are markdown not rst. It would be proper to call the file changelog_since_last_release.md instead.
• The release script should use bob_new_version script to avoid issues like this in future. If the script is not flexible enough, we can easily change it.
• It would have been better to also point to merge requests in the changelogs. This way you can click in Gitlab's interface and see the actual code change easily.
• The default tag for packages without any tag should be 0.0.1 instead of 1.0.0. Making a package version 1 means that the author will follow strict semantic versioning from now and the package is stable: https://semver.org/ However, this is not true at all.
• Most packages (with only CI changes) should have gotten a patch version instead of minor.
• The tags need to be sorted based on their version not their latest date.
• The versions need to be bumped correctly.
• Deprecate the new_version script in bob.extension.

See https://gitlab.idiap.ch/bob/bob.extension/tags

It has increased bob.blitz from 2.0.14 to 2.1.9 https://gitlab.idiap.ch/bob/bob.blitz/tags, but why? :D

Yes,

All minors/major bumps have this problem.

Once the release script is fixed, how can we fix the packages?

Is it ok to delete all the last tags and the stables from https://www.idiap.ch/software/bob/conda/label/stable ?

These are all released to PyPI too. FYI.

Well, we'll have to.

• Fix the release script
• Remove the last tags from all packages
• Delete all the conda stables
• About PyPI, well we are f**ed. We can delete all the last releases, but we can't release the same versions again.

Shall we start from the tags? ping @amohammadi @pkorshunov @andre.anjos

Here are my comments for the release script. Sorry I could not review it earlier.

• The tag changelogs on gitlab are markdown not rst. It would be proper to call the file changelog_since_last_release.md instead.
• The release script should use bob_new_version script to avoid issues like this in future. If the script is not flexible enough, we can easily change it.
• It would have been better to also point to merge requests in the changelogs. This way you can click in Gitlab's interface and see the actual code change easily.
• The default tag for packages without any tag should be 0.0.1 instead of 1.0.0. Making a package version 1 means that the author will follow strict semantic versioning from now and the package is stable: https://semver.org/ However, this is not true at all.
• Most packages (with only CI changes) should have gotten a patch version instead of minor.

Well,

The issue in the script is pretty clear. Look https://gitlab.idiap.ch/bob/bob.admin/blob/master/release/release_bob.py#L101 and https://gitlab.idiap.ch/bob/bob.admin/blob/master/release/release_bob.py#L103

I wonder how the script has managed to increase the version of bob.blitz from 2.0.14 to 2.1.9. There must be other issues in the script because the tagged version is not even 2.1.14.

I wonder how the script has managed to increase the version of bob.blitz from 2.0.14 to 2.1.9. There must be other issues in the script because the tagged version is not even 2.1.14.

The tags returned by the gitlab API are not sorted by the release script. Look at the list of tags returned for bob.blitz

[<ProjectTag name:v2.1.9>, <ProjectTag name:v2.0.9>, <ProjectTag name:v2.0.8>, <ProjectTag name:v2.0.7>, <ProjectTag name:v2.0.6>, <ProjectTag name:v2.0.5>, <ProjectTag name:v2.0.4>, <ProjectTag name:v2.0.3>, <ProjectTag name:v2.0.2>, <ProjectTag name:v2.0.14>, <ProjectTag name:v2.0.13>, <ProjectTag name:v2.0.12>, <ProjectTag name:v2.0.11>, <ProjectTag name:v2.0.10>, <ProjectTag name:v2.0.1>, <ProjectTag name:v2.0.0b1>, <ProjectTag name:v2.0.0>]

I had code in the release folder to sort the tags: 8afcc887

I found another issue. Most packages are bumped to a minor version while I think they should have gotten a patch version only. Only their CI had changed and no functionality was added.

People must have confused what is major/minor/patch. The versions are like this: v major.minor.patch. From https://semver.org/

Summary

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

    MAJOR version when you make incompatible API changes,
    MINOR version when you add functionality in a backwards-compatible manner, and
    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.

I found another issue. Most packages are bumped to a minor version while I think they should have gotten a patch version only. Only their CI had changed and no functionality was added.

No package should have been given a major version. We didn't break backward compatibility in this 3.1 release AFAIK.

Follow below a list of the last two tags of all released packages. Almost all of them need to be released again.

bob.buildout -- v2.1.5 --> v2.1.6
bob.extension -- v2.4.5 --> v3.4.5
bob.blitz -- v2.0.9 --> v2.1.9
bob.core -- v2.1.9 --> v2.2.9
bob.io.base -- v3.0.2 --> v3.1.2
bob.math -- v3.0.0 --> v3.1.0
bob.measure -- v2.4.1 --> v3.4.1
bob.io.image -- v2.3.0 --> v2.4.0
bob.db.base -- v2.3.2 --> v3.3.2
bob.io.video -- v2.0.8 --> v2.1.8
bob.io.matlab -- v2.0.9 --> v2.1.9
bob.io.audio -- v2.0.6 --> v2.1.6
bob.sp -- v2.0.9 --> v2.1.9
bob.ap -- v2.1.5 --> v2.2.5
bob.ip.base -- v2.1.0 --> v2.2.0
bob.ip.color -- v2.0.9 --> v2.1.9
bob.ip.draw -- v2.0.9 --> v2.1.9
bob.ip.gabor -- v2.0.9 --> v2.1.9
bob.learn.activation -- v2.0.9 --> v2.1.9
bob.learn.libsvm -- v2.0.9 --> v2.1.9
bob.learn.linear -- v2.1.2 --> v2.2.2
bob.learn.mlp -- v2.1.6 --> v2.2.6
bob.learn.boosting -- v2.0.9 --> v2.1.9
bob.db.iris -- v2.1.1 --> v2.2.1
bob.learn.em -- v2.1.0 --> v2.2.0
bob.db.wine -- v2.0.9 --> v2.1.9
bob.db.mnist -- v2.1.1 --> v2.2.1
bob.db.atnt -- v2.0.9 --> v2.1.9
bob.ip.facedetect -- v2.1.4 --> v2.2.4
bob.ip.optflow.hornschunck -- v2.0.9 --> v2.1.9
bob.ip.optflow.liu -- v2.0.9 --> v2.1.9
bob.ip.flandmark -- v2.1.6 --> v2.2.6
gridtk -- v1.5.0 --> v1.6.0
bob.ip.qualitymeasure -- v1.0.5 --> v1.1.5
bob.ip.skincolorfilter -- v0.0.3 --> v0.1.3
bob.ip.facelandmarks -- v1.0.4 --> v1.1.4
bob.ip.dlib -- v1.0.2 --> v1.0.3
bob.db.arface -- v2.1.4 --> v2.2.4
bob.db.asvspoof -- v1.1.7 --> v1.2.7
bob.db.atvskeystroke -- v2.1.5 --> v2.2.5
bob.db.avspoof -- v2.2.8 --> v2.3.8
bob.db.banca -- v2.1.5 --> v2.2.5
bob.db.biosecure -- v2.1.5 --> v2.2.5
bob.db.biosecurid.face -- v2.1.8 --> v2.2.8
bob.db.casme2 -- v2.1.5 --> v2.2.5
bob.db.caspeal -- v2.1.5 --> v2.2.5
bob.db.cohface -- v1.0.4 --> v1.1.4
bob.db.frgc -- v2.1.3 --> v2.2.3
bob.db.gbu -- v2.1.4 --> v2.2.4
bob.db.hci_tagging -- v1.0.4 --> v1.1.4
bob.db.ijba -- v2.0.3 --> v2.1.3
bob.db.kboc16 -- v2.0.9 --> v2.1.9
bob.db.lfw -- v2.1.5 --> v2.2.5
bob.db.livdet2013 -- v2.0.6 --> v2.1.6
bob.db.mobio -- v2.1.5 --> v2.2.5
bob.db.msu_mfsd_mod -- v2.2.3 --> v2.3.3
bob.db.multipie -- v2.1.4 --> v2.2.4
bob.db.nist_sre12 -- v3.0.3 --> v3.1.3
bob.db.putvein -- v1.2.1 --> v1.3.1
bob.db.replay -- v3.0.3 --> v3.1.3
bob.db.replaymobile -- v1.1.3 --> v1.2.3
bob.db.scface -- v2.1.5 --> v2.2.5
bob.db.utfvp -- v2.4.1 --> v3.4.1
bob.db.verafinger -- v1.0.0 --> v2.0.0
bob.db.fv3d -- v1.0.0 --> v1.1.0
bob.db.xm2vts -- v2.1.4 --> v2.2.4
bob.db.youtube -- v2.1.4 --> v2.2.4
bob.db.cuhk_cufs -- v2.1.3 --> v2.2.3
bob.bio.base -- v4.2.1 --> v4.2.2
bob.bio.gmm -- v3.1.0 --> v3.2.0
bob.bio.face -- v3.3.0 --> v4.3.0
bob.bio.spear -- v3.1.1 --> v3.2.1
bob.bio.video -- v3.3.0 --> v3.4.0
bob.bio.vein -- v1.0.1 --> v1.1.1
bob.db.voxforge -- v2.2.0 --> v2.3.0
bob.pad.base -- v1.0.8 --> v2.0.8
bob.pad.face -- v1.0.0 --> v2.0.0

So guys, we need to fix this.

I've looked ALL the commits from the released packages and excluding bob.bio.base, that had a commit 15 hours ago (an update in the conda recipe), we didn't have any commit in the master branch.

The nightlies are green, so we are good to go.

I'm proposing the following plan:

• Put on hold ALL the Merge-Requests to the master branches of ALL published packages.
• git reset --hard HEAD~2 for ALL published packages (special treat to bob.bio.base)
• Remove the last tags from ALL published packages
• Fix Pavel's release script (it's the best we have so far and despite this error, works). Later on we can implement other solution.
• Carefully review the new versions of all packages (check if it's patch, minor or major)
• Delete all the conda packages from the stable channel (shall we clean the betas too?).
• Delete all the stable docs
• Go on Pypi and delete the last releases ONE by ONE (there's no other way).
• Start over the releasing process

What do you think guys?

Very likely I missed something (I don't have the full picture of it).

A feedback would be appreciated. ping @amohammadi @andre.anjos

Thanks

@tiago.pereira your analysis is wrong. For example, it says bob.blitz -- v2.0.9 --> v2.1.9 but that is wrong.

@tiago.pereira your analysis is wrong. For example, it says bob.blitz -- v2.0.9 --> v2.1.9 but that is wrong.

Yeah, you are right. I think the sorting tags from here 8afcc887 is not working properly.

git reset --hard HEAD~2 for ALL published packages (special treat to bob.bio.base)

This is very dangerous. Is it possible that you do this in a different way? For example, can you confirm the commit messages before doing this? Deleting the last to commit messages without checking properly is really dangerous.

Fix Pavel's release script (it's the best we have so far and despite this error, works). Later on we can implement other solution.

I have already pointed out several issues with this script: #79 (comment 27069) they need to be fixed before we use it.

Delete all the stable docs

You do not need to delete the stable folders but you need to delete the tag (e.g. v3.4.5) folders.

git reset --hard HEAD~2 for ALL published packages (special treat to bob.bio.base)

This is very dangerous. Is it possible that you do this in a different way? For example, can you confirm the commit messages before doing this? Deleting the last to commit messages without checking properly is really dangerous.

I'm planning to do this locally and push it one by one (will be painful, but we can't risk (we don't have a staging gitlab))

Fix Pavel's release script (it's the best we have so far and despite this error, works). Later on we can implement other solution.

I have already pointed out several issues with this script: #79 (comment 27069) they need to be fixed before we use it.

Do you have some time to approach this?

Delete all the stable docs

You do not need to delete the stable folders but you need to delete the tag (e.g. v3.4.5) folders.

ok