Closed aleksander0m closed 3 years ago
sevan
commented
3 years ago Hi @aleksander0m
Many thanks for the pull request. 2 things
We're not doing semantic versioning, just make it v1.6.
The openmoko distro files are not part of the build and don't do any harm being there. Drop the removal commit and I'll merge it to roll a new release.
aleksander0m
commented
3 years ago @sevan I've updated the branch with your suggested changes, let me know what you think. The branch itself still says 1.5.1 in the branch name; just wanted to avoid having to create a full new merge request.
If you merge this, please tag also the commit with the configure.ac version bump as 1.6, so that it's clear which one is the new version and distros don't need to guess :)
Also, unrelated, but I needed it in my own build, maybe merge this https://github.com/coova/coova-chilli/pull/525 before the new 1.6 release merge? Thanks!
aleksander0m
commented
3 years ago @sevan in attempting to clear the release mess with 1.5 we've done another little mess with 1.6 I'm afraid :) Maybe it's just me being too strict on all this, but I think being strict helps packagers to do the downstream releases easier instead of trying to guess things...
My commit that said "build: update version to 1.6" no longer says that in git master, because the PR was merged squashing all commits in the branch together. The different commits in the branch made sense to have them separated, each commit was doing a different thing. Merging them all together in one single squashed commit also made github take the original PR text as commit message, which is why there is no commit in the final commit list saying the "build: update version to 1.6"
In my opinion, the tag for 1.6 should have gone to the commit that bumps configure.ac to 1.6, not to the commit that updates ChangeLog and makes no reference to the commit being a new release. Looking at the commit list, it isn't clear which commit is the one that made the release 1.6: https://github.com/coova/coova-chilli/commits/master and if someone builds e.g. commit 090526b0a7cf03bf8ec7525e7a602e35ad936a7d they will get the version reported as 1.6 even if the 1.6 tag was added to a later commit.
Cheers!
Hey @sevan
I've tried to cleanup a bit the build and packaging so that the version provided by the sources (1.5.1) is the same one as the git tag in github (you would need to tag the latest commit in this PR as 1.5.1).
I've also reworked the packaging sources leaving only the one for DEBs and the one for RPMs (from distro/redhat), and sync-ed version numbers on those as well.
Let me know what you think, or if I can help with anything else.