ID: 188PHID: PHID-TASK-pcplruxkrh4fv2jcwnzsAuthor: PatrickStatus at Migration Time: resolvedPriority at Migration Time: High
One last thing before adding the qubes-whonix package to Whonix’s repository. (T182) We should discuss which version scheme to use.
I mindlessly bumped the version number in debian/changelog(0:9.6-1) to (0:9.7-1). (Did that, because the changelog needs to include at least two entries (otherwise we run into the “requires close ITP” lintian warning).
Now realized, that you want to make the version numbers of the package on par with Whonix release.
I don’t think this is going to work out well. Let’s say I or you made a signed git tag using 9.6. Then realized, that we need any last minute fixes. What version number would we use then? Deleting git tags seems out of question. (Users who already got them, won’t get them overridden by git design for security reasons. Unless they manually delete them, there would be two different git tags in the wild pointing to different git hashes.) Or another case. Let’s say you wanted to make the package work with Whonix 10, but there are no final tags for it yet.
What about using a version scheme that is independent from the Whonix release?
2015-02-17 07:46:23 UTC
Maybe what @nrgaway was intending was to bump the trailing dash number suffix, like from 9.6-1 to 9.6-2 etc.
I had been thinking something similar as @Patrick that anchoring the qubes-whonix package versioning to the main Whonix version might be too rigid and limiting in various cases.
Or falsely anchoring to the main Whonix version could put social pressure on a new package version release, even when one is not needed for qubes-whonix, as some people might be confused and assume qubes-whonix is out of date every single time the Whonix version goes up. As some Whonix releases probably won’t affect qubes-whonix at all.
Maybe having normal independent versioning of qubes-whonix like the other Whonix packages would be okay?
2015-02-17 08:01:54 UTC
2015-02-17 13:49:51 UTC
Yes.
! In T188#2305, @WhonixQubes wrote:@nrgaway was intending was to bump the trailing dash number suffix, like from 9.6-1 to 9.6-2 etc.
That would work, but it would be a very hackish solution. Trailing dash numbers are for Debian revisions as per Debian policy. Only supposed to be changed if upstream code didn’t change, but if the Debian packaging changed.
! In T188#2307, @WhonixQubes wrote:@Patrick is there documentation that describes the versioning format conventions used for the structure and incrementing of other Whonix packages?
Created T189 for it.
2015-02-18 21:16:32 UTC
2015-02-19 19:25:55 UTC
What if we reach 9.9? I was wondering about such cases. Hopefully would never happen. We’re not that far away with 9.6. Then I’d use for Whonix 9.9.1, 2, 3, etc. Which would confuse that plan.
2015-02-22 20:58:56 UTC
After 9.9 is 9.10
I changed by version scheme to use 9.6.x since the qubes-whonix code is so closely tied to Whonix versions. It is very possible that no changes would need to be done to qubes-whonix for a 9.8 Whonix release, and in that case would carry on using 9.6 version or just create a new tag.
I changed the debian/changelog to reflect the version change so you will have a merge conflict.
I also added a version file in the root directory that contains the current version number. It is used within qubes-builder to increase the debian/changelog version and history.
I also created a Whonix9 branch within the qubes-whonix repo as that is where all qubes-whonix code and tags related to Whonix9 will reside (stable). I will soon create a Whonix10 branch to begin packaging for it as well. I plan on using the master branch for development.
I am thinking you can use an epoc of 1, where I use an epoc of 0. That should resolve any conflicts you are having and you can then version the Debian package the same as mine for the initial version like follows:
nrgaway repo version:
Whonix/Patrick version:
1:9.6.2-1
1:9.6.2-2 - Some change you make different from upstream
1:9.6.2-3 - Some more changes you make different from upstream
If you still have an issue with my name as a maintainer, just replace it with yours or do what ever is required to make this a smooth process.
This should remove the last blocker as currently listed in T182. If you are satisfied with these changes, I would ask if you could create a signed version tag since I am using your git repo to do the actual building of the qubes-whonix package and it fails when a tag is not signed or present.
Any time I release an update I will bump version, so next version will be:
2015-02-22 22:33:41 UTC
Sounds good.
! In T188#2392, @nrgaway wrote:debian/changelog to reflect the version change so you will have a merge conflict.
If you could merge and add on top, I would prefer that. Not a big deal in this case. But in other cases, perhaps I am just a bit inexperienced with merge conflict resolution.
If you still have an issue with my name as a maintainer
None.
I am thinking you can use an epoc of 1, where I use an epoc of 0. That should resolve any conflicts you are having and you can then version the Debian package the same as mine for the initial version like follows:
You lost me here. What conflicts do you mean?
2015-02-22 22:40:33 UTC
2015-02-22 22:44:54 UTC
I was talking about the version conflict you had with Debian package lintian warnings (“requires close ITP” lintian warning. Now there are more than 2 log entries this may not be the case anymore.
I just thought the version number of 9.7-1 was confusing. Anyway, if there is no problem with lintian anymore you could just version it as 9.6.2-1? or something like that. The only reason I suggested epoc of one was to override my versions always while being able to keep same version numbers.
2015-02-22 22:53:32 UTC
I was talking about the version conflict you had with Debian package lintian warnings (“requires close ITP” lintian warning.
Ah. (Anyhow, but epoch wouldn’t help there.)
Now there are more than 2 log entries this may not be the case anymore.
Ok.
Anyway, if there is no problem with lintian anymore you could just version it as 9.6.2-1?
There are still lintian issues (T186), but those aren’t a blocker here.
could just version it as 9.6.2
Tagged as 9.6.2 and pushed to github.
There could be one issue. The one I wanted to talk about. My branch is 1 commit ahead. Added changelog.upstream as well as upstream changelog creation to debian/rules.
If that is no issue, I can upload it to Whonix’s APT repository. (T182)
2015-02-22 23:38:03 UTC
Sorted that out. Summary of IRC discussion can be found here:https://phabricator.whonix.org/T193#2430
From my side, feel free to close this… Or discuss further… Or change… Thanks to Debian packaging’s epoch feature, the version format can always be changed.
2015-05-27 22:57:27 UTC