Dne 21. 10. 22 v 15:33 Vít Ondruch napsal(a):
Dne 21. 10. 22 v 13:56 Mamoru TASAKA napsal(a):* Now rpm supports tilde, tilde is regarded as older than non-tilde version. So we can use, say, ruby-3.2.0~preview2-170.20221021gitabcdefg.fc38, for example,without "resetting" release number to 0.1.XXXX.
Looking into this, I don't think we can use the tilde easily. Yes, it would work for the `previewN` releases, but how would you envision this for regular snapshots?
So should we keep using the `preview2` suffix after the preview2 is released and up until e.g. the preview3 is out? Possibly in combination with caret?
For example given these releases: 3.2.0~20220916git6ad6994457 3.2.0~20221012git70bc8cc6c 3.2.0~preview1 the scheme would not work: ~~~ $ rpmdev-vercmp 3.2.0~20220916git6ad6994457 3.2.0~20221012git70bc8cc6c 3.2.0~20220916git6ad6994457 < 3.2.0~20221012git70bc8cc6c $ rpmdev-vercmp 3.2.0~20221012git70bc8cc6c 3.2.0~preview1 3.2.0~20221012git70bc8cc6c > 3.2.0~preview1 ~~~ But it could be better, if the date is always first: 3.2.0~20220916git6ad6994457 3.2.0~20221012git70bc8cc6c 3.2.0~20221015preview1 3.2.0~20221101preview1^git4b1504ae0a But I am not sure this is not overcomplicated. So any other scheme which would work? 😇BTW it is interesting, that it seems the guidelines suggest against using release for snapshot information [1] and actually encourages usage of the caret. This is new to me. I wish they have announced the changes.
Vít[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_traditional_versioning_with_part_of_the_upstream_version_information_in_the_release_field
Then we can set the release number of subpackages (such as rubygem-io-console) to (0.5.12-)170.gitabcdefg.fc38, so now we don't have to fight with release number,just we have to keep increasing this.The release number was never priority for my local experiments. But the tilde is probably something to consider. Not sure what impact it will have on the work with the archive name etc. But it could help with the Copr rebuilds and what not. Thx for pointing this out. I'll try to take 2nd look.Vít* And perhaps on 2022/11/E, I guess ruby3.2 would almost stable. Regards, Mamoru _______________________________________________ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.orgFedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelinesList Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
