Skip to content

Prepare release of 1.0.0 #74

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
okurz merged 1 commit into from
Apr 2, 2025
Merged

Prepare release of 1.0.0 #74

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 8 additions & 0 deletions Changes
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,14 @@
Revision history for Perl extension Mojo-IOLoop-ReadWriteProcess

{{$NEXT}}
1.0.0 2025-03-17 12:20:20Z
Copy link
Collaborator

@perlpunk 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
1.0.0 2025-03-17 12:20:20Z
v1.0.0 2025-03-17 12:20:20Z

- Various test fixes
- Fix race condition in `is_running` when `kill_whole_group` is set
- Fix handling process groups when initial process is not running anymore
- Add Minilla to the ci target
- Update minil.toml to have the harness arguments enabled
- Mention syntactic sugar to help when debugging
- Enable support for MacOSX (darwin)

0.34 2023-09-18T15:47:18Z
- Adapt to deprecation of spurt in upstream Mojolicious
Expand Down
2 changes: 1 addition & 1 deletion META.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -69,7 +69,7 @@
"web" : "https://github.com/openSUSE/Mojo-IOLoop-ReadWriteProcess"
}
},
"version" : "0.34",
"version" : "1.0.0",
Copy link
Collaborator

@perlpunk 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",

"x_contributors" : [
"Adam Williamson <awilliam@redhat.com>",
"Clemens Famulla-Conrad <cfamullaconrad@suse.de>",
Expand Down
2 changes: 1 addition & 1 deletion lib/Mojo/IOLoop/ReadWriteProcess.pm
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
package Mojo::IOLoop::ReadWriteProcess;

our $VERSION = '0.34';
our $VERSION = '1.0.0';
Copy link
Collaborator

@perlpunk 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
our $VERSION = '1.0.0';
our $VERSION = 'v1.0.0';

Copy link
Member Author

@okurz okurz Mar 31, 2025

Choose a reason for hiding this comment

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

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

Copy link
Member

@kalikiana kalikiana Mar 31, 2025

Choose a reason for hiding this comment

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

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.

Copy link
Collaborator

@perlpunk perlpunk Mar 31, 2025

Choose a reason for hiding this comment

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

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.

Copy link
Member Author

@okurz okurz Mar 31, 2025

Choose a reason for hiding this comment

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

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.

  1. Because semver.org says don't do it
  2. 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
  3. Because a version number needs to be a number.
  4. 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:

  1. os-autoinst+openQA
  2. https://github.com/okurz/openqa_review
  3. Firefox
  4. Chromium
  5. https://github.com/Perl/perl5/blob/blead/META.yml#L108
  6. Mojolicious
  7. Linux

Copy link
Collaborator

@perlpunk perlpunk Mar 31, 2025

Choose a reason for hiding this comment

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

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

Copy link
Member

@kalikiana kalikiana Mar 31, 2025

Choose a reason for hiding this comment

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

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

Copy link
Collaborator

@perlpunk perlpunk Mar 31, 2025

Choose a reason for hiding this comment

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

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.

Copy link
Member

@aylen384 aylen384 Apr 2, 2025

Choose a reason for hiding this comment

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

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.

Copy link
Collaborator

@perlpunk perlpunk Apr 2, 2025 •
edited
Loading

Choose a reason for hiding this comment

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

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?


use Mojo::Base 'Mojo::EventEmitter';
use Mojo::File 'path';
Expand Down
Loading