Skip to content
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.

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

DRAFT: Add support for --without-test and --with-test #667

Open
wants to merge 3 commits into
base: devel
Choose a base branch
from

Conversation

dboehmer
Copy link
Contributor

Implements proposal from #651.

@miyagawa
Copy link
Owner

miyagawa commented Aug 28, 2023

The diff looks sensible. As you stated, the similarity between --without-test and --notest would be pretty confusing but the ship might have already sailed.

Having said that I have not released cpanm for the last 5 years except critical bug/security fix from the master branch, and I'd be very careful of shipping the changes accumulated in the develop branch. I'm not intending to let you down but just telling you the reality, that this might never get released.

@dboehmer
Copy link
Contributor Author

Oh, that is a bit sad to hear. I was surprised that you seemingly acknowledged the proposal. One might call this quite a special feature request and I saw issues with naming and implementation. I only went one to create the PR after you positive feedback.

Do you consider cpanm that much stable and mature that no more releases are necessary or is the project in a dead end somehow?

@miyagawa
Copy link
Owner

miyagawa commented Aug 28, 2023

Do you consider cpanm that much stable and mature that no more releases are necessary

Yeah it's more of this. It is considered the very first thing people would install after installing a new perl, often times in an automated way in CI environments, and any behavior change could bring a negative experience even if it was to fix bad defaults.

Now, I understand that this PR doesn't change any behaviors unless the option is specified. What's worrying is the other changes in this branch that were not released. Blame the pandemic for this, since I tended to release once in a year when the perl toolchain people got together at a hackathon, but that was cancelled for the last few years.

I only went one to create the PR after you positive feedback.

Sorry for the false(?) positive feedback then. I should've been clear and warned you about it -- given the amount of changes I hope you didn't spend too much time on it though.

I recommend taking a look at cpm if this is something that needs to be addressed critically in your project, to see if there's a way to achieve it with cpm.

@dboehmer
Copy link
Contributor Author

dboehmer commented Sep 4, 2023

What about ditching the current devel branch and restarting the development cycle on current maint and cherry-picking/merging changes one by one?

I don’t consider my PR too important but I think having a working release model for cpanm is crucial for the Perl ecosystem. In the current state everything is doomed to get worse by time … Can I do anything to help with that? Does it need any other people to get this started?

@miyagawa
Copy link
Owner

miyagawa commented Sep 4, 2023

I think having a working release model for cpanm is crucial for the Perl ecosystem.

the master branch is in a releasable state and that's how the bug fixes and security releases have been maintained in the past few years. This happened a few weeks ago when the latest perl dev release broke cpanm.

@dboehmer
Copy link
Contributor Author

dboehmer commented Sep 4, 2023

Okay, good to know. 👍 But I didn’t meant hotfix releases only. I expected cpanm to have releases regularly so things can improve over time. If only security fixes are possible cpanm will age badly. Can we avoid that?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants