Information
ID: 188
PHID: PHID-TASK-pcplruxkrh4fv2jcwnzs
Author: Patrick
Status at Migration Time: resolved
Priority at Migration Time: High
Description
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
from (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?
Comments
WhonixQubes
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?
WhonixQubes
2015-02-17 08:01:54 UTC
Patrick
2015-02-17 13:49:51 UTC
Yes.
! In T188#2305, @WhonixQubes wrote:
Maybe what @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.
nrgaway
2015-02-18 21:16:32 UTC
Patrick
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.
nrgaway
2015-02-22 20:58:56 UTC
After 9.9 is 9.10 Yes it may look confusing if you are interpreting the 10 as a decimal point, but for software this is common practise.
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:
Patrick
2015-02-22 22:33:41 UTC
Sounds good.
! In T188#2392, @nrgaway wrote:
I changed the 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?
An epoch of 1 will always and forever take precedence over an epoch of 0.
Patrick
2015-02-22 22:40:33 UTC
nrgaway
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.
Patrick
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)
Patrick
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.
Patrick
2015-05-27 22:57:27 UTC