Prepare release of 1.0.0 #74

okurz · 2025-03-31T11:20:48Z

Use semver.org compatible version format and jump to 1.0.0 to avoid any
version computing ambiguities.

As per
semver/semver.org#1 and
https://semver.org/#is-v123-a-semantic-version the version number itself
does not include a "v"-prefix itself however the prefix can be included
in denoting a version string.

References:

codecov · 2025-03-31T11:24:53Z

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.25%. Comparing base (f596a13) to head (804fce2).
Report is 2 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master      #74      +/-   ##
==========================================
+ Coverage   81.39%   89.25%   +7.86%     
==========================================
  Files          27       27              
  Lines         903      903              
  Branches      207      207              
==========================================
+ Hits          735      806      +71     
+ Misses        118       22      -96     
- Partials       50       75      +25

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Martchus

I'd squash the commits. I agree with switching to semver. Not sure whether it would make sense to stay at a "0.x.x", though (as there's probably still a lot left to improve or cleanup).

perlpunk · 2025-03-31T12:13:30Z

Changes

 Revision history for Perl extension Mojo-IOLoop-ReadWriteProcess

 {{$NEXT}}
+1.0.0 2025-03-17 12:20:20Z


Suggested change

1.0.0 2025-03-17 12:20:20Z

v1.0.0 2025-03-17 12:20:20Z

perlpunk · 2025-03-31T12:13:39Z

META.json

      }
   },
-   "version" : "0.34",
+   "version" : "1.0.0",


Suggested change

"version" : "1.0.0",

"version" : "v1.0.0",

perlpunk · 2025-03-31T12:13:46Z

lib/Mojo/IOLoop/ReadWriteProcess.pm

 package Mojo::IOLoop::ReadWriteProcess;

-our $VERSION = '0.34';
+our $VERSION = '1.0.0';


Suggested change

our $VERSION = '1.0.0';

our $VERSION = 'v1.0.0';

Sorry, I don't see why we should do that. You referenced a 7 year old blog article from an individual and a Perl module within your personal scope. Every project using a sane version number I now does not feature a v-prefix so I don't see why we should do that

Said blog article gives a perfectly valid reason. Versions should be strings to preserve all digits.

That said, this string is quoted. So it is a string in any case.

Sorry, I don't see why we should do that. You referenced a 7 year old blog article from an individual and a Perl module within your personal scope. Every project using a sane version number I now does not feature a v-prefix so I don't see why we should do that

The blog article is still relevant, from a very active perl toolchain member, and it recommends that one should use both a v prefix and two dots.
And I recommend that too. It's just clearer.
Why don't you want to do that? I don't understand it.

I don't know how you conclude "Every project using a sane version number I now does not feature a v-prefix".
Give me some module examples then. And don't link to openSUSE spec files, because there the v is removed.
The v is only for the CPAN module. It does not end up in the spec file.

Sorry, I don't see why we should do that. You referenced a 7 year old blog article from an individual and a Perl module within your personal scope. Every project using a sane version number I now does not feature a v-prefix so I don't see why we should do that

The blog article is still relevant, from a very active perl toolchain member, and it recommends that one should use both a v prefix and two dots. And I recommend that too. It's just clearer. Why don't you want to do that? I don't understand it.

Because semver.org says don't do it

Because whenever I read about version formats in the past the conclusion was always to not include the v in the version itself and as necessary only prefix it downstream

Because a version number needs to be a number.

Because we don't do it for all other projects that I maintain or co-maintain

I don't know how you conclude "Every project using a sane version number I now does not feature a v-prefix". Give me some module examples then. And don't link to openSUSE spec files, because there the v is removed. The v is only for the CPAN module. It does not end up in the spec file.

I am not sure what you mean with "module examples". I have no problem including the v in some CPAN specifics as necessary. My point is that I don't see (yet) why the version in the project itself should include the v. Some examples are:

os-autoinst+openQA

https://github.com/okurz/openqa_review

Firefox

Chromium

https://github.com/Perl/perl5/blob/blead/META.yml#L108

Mojolicious

Linux

Look at https://metacpan.org/recent

Most modules which use 2 dots are using the v prefix.

Because semver.org says don't do it

The prefix is about how to specify the version in a perl module.

To get the semver version of such a perl module you just strip the v.

Because whenever I read about version formats in the past the conclusion was always to not include the v in the version itself and as necessary only prefix it downstream

Again, it's about how you specify it in perl.

Because a version number needs to be a number.

Oh? Is 1.0.0 a number?

Because we don't do it for all other projects that I maintain or co-maintain

So, how many CPAN modules do you maintain?

It's possible to leave the v off, but it makes it clearer that the new version format is used.

And I don't see any problem with it.
And repology also doesn't have a problem with it: https://repology.org/project/perl%3Ayaml-pp/versions

So what do we get from prefixing with v? I don't see that discussed in the blog.

Only clarity about the version format, like I said.
https://blogs.perl.org/users/grinnz/2018/04/a-guide-to-versions-in-perl.html

It disambiguates these two types with simple rules: if the version contains a leading "v" or more than one decimal separator, it's a version tuple; otherwise, it's a decimal number. For this reason it's best to include both a leading "v" and at least two decimal separators for clarity when using tuple versions.

And I don't see any problem with it. And repology also doesn't have a problem with it: https://repology.org/project/perl%3Ayaml-pp/versions

In the spec file of that very package you are duplicating the version string - you define it once with the v prefix and once without:
https://build.opensuse.org/projects/openSUSE:Factory/packages/perl-YAML-PP/files/perl-YAML-PP.spec?expand=1

At least use %{version} to devine the other var:

%define cpan_version v%{version}

Or this all could be simplified by not using v prefix.

Or this all could be simplified by not using v prefix.

Well, it depends on how you define "simplify".

As you hopefully know, we are using cpanspec to generate the spec files. I don't write that manually.

The cpan_version definition thing is a general thing to handle the case, when the spec version differs from the cpan version, specifically what the tarball has in its name.

So, let's have a look Mojolicious:
The tarball is called Mojolicious-9.39.tar.gz
The normalized version for rpm is 9.390.0

https://build.opensuse.org/projects/devel:languages:perl/packages/perl-Mojolicious/files/perl-Mojolicious.spec?expand=1

Version: 9.390.0 Release: 0 # 9.39 -> normalize -> 9.390.0 %define cpan_version 9.39

Now you are suggesting, that if cpan_version is something like v1.2.3 that I do

%define cpan_version v%{version}

but in all other cases (like for Mojolicious) I can't use this.

That would make the cpanspec code even more complicated.

Or this all could be simplified by not using v prefix.

And even if I would do this for YAML-PP, what about the thousands other CPAN modules that don't?

Changes

It seems my opinion as a long term CPAN author isn't seen as relevant

perlpunk · 2025-03-31T14:47:11Z

I dismissed my review. Do what you have to do

okurz · 2025-03-31T15:58:14Z

@perlpunk

It seems my opinion as a long term CPAN author isn't seen as relevant

Your opinion is very relevant but before I change the version format I would prefer to understand the reasoning

Use semver.org compatible version format and jump to 1.0.0 to avoid any version computing ambiguities. As per semver/semver.org#1 and https://semver.org/#is-v123-a-semantic-version the version number itself does not include a "v"-prefix itself however the prefix can be included in denoting a version string. References: * https://semver.org/ * https://blogs.perl.org/users/grinnz/2018/04/a-guide-to-versions-in-perl.html * https://github.com/perlpunk/perl5-module-meta * semver/semver.org#1 Update Changes Co-authored-by: Tina Müller (tinita) <cpan2@tinita.de>

perlpunk

we should make a release soon, so i approved it

okurz mentioned this pull request Mar 31, 2025

Prepare release of 0.35 #67

Closed

Martchus reviewed Mar 31, 2025

View reviewed changes

perlpunk reviewed Mar 31, 2025

View reviewed changes

META.json

}

},

"version" : "0.34",

"version" : "1.0.0",

Copy link

Collaborator

perlpunk Mar 31, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change

"version" : "1.0.0",

"version" : "v1.0.0",

perlpunk previously requested changes Mar 31, 2025

View reviewed changes

perlpunk reviewed Mar 31, 2025

View reviewed changes

Changes Outdated Show resolved Hide resolved

okurz force-pushed the feature/v1.0.0 branch from ff2ede6 to 804fce2 Compare April 1, 2025 09:01

perlpunk approved these changes Apr 1, 2025

View reviewed changes

okurz merged commit 73447c9 into openSUSE:master Apr 2, 2025
14 checks passed

okurz deleted the feature/v1.0.0 branch April 2, 2025 07:20

Prepare release of 1.0.0 #74

Prepare release of 1.0.0 #74

Uh oh!

Conversation

okurz commented Mar 31, 2025

Uh oh!

codecov bot commented Mar 31, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

Martchus left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

perlpunk Apr 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

perlpunk commented Mar 31, 2025

Uh oh!

okurz commented Mar 31, 2025

Uh oh!

perlpunk left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

codecov bot commented Mar 31, 2025 •

edited

Loading

Martchus left a comment •

edited

Loading

perlpunk Apr 2, 2025 •

edited

Loading