search

conda-forge / perl-feedstock

A conda-smithy repository for perl.
BSD 3-Clause "New" or "Revised" License
3 stars 32 forks source link

Include perl 5.22.0 #10

Closed bgruening closed 7 years ago

conda-forge-linter commented 7 years ago

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

bgruening commented 7 years ago

@ocefpaf can I get a merge please? :) Just out of interest if I want to add yet another release, a new branch is needed, correct? Should this branch then names according to the legacy-version?

ocefpaf commented 7 years ago

@ocefpaf can I get a merge please? :)

I would like if @conda-forge/perl could take a look before I use my "sudo" powers to merge it.

Just out of interest if I want to add yet another release, a new branch is needed, correct? Should this branch then names according to the legacy-version?

Unless you want to keep maintaining them with patches and updates I do not recommend that. I would add the oldest one you want now, in this PR, and then keep updating it until you reach the current version.

bgruening commented 7 years ago

Unless you want to keep maintaining them with patches and updates I do not recommend that. I would add the oldest one you want now, in this PR, and then keep updating it until you reach the current version.

I was just wondering, because I think it is worth to maintain different versions of one package for reproducibility reasons. I don't care much about perl, but conda-forge should maybe have a recommended way to address this besides the git history.

Thanks!

ocefpaf commented 7 years ago

but conda-forge should maybe have a recommended way to address this besides the git history.

I disagree. We need active feedstocks only for active packages. Otherwise the git is enough for reproducibility.

bgruening commented 7 years ago

@ocefpaf who decides what is active and what is not? Assuming I have an older perl with an ssl bug, I need to get this version out of the git history, patch it, merge it, revert everything to get to a newer version?

ocefpaf commented 7 years ago

@ocefpaf who decides what is active and what is not?

The maintainers.

Assuming I have an older perl with an ssl bug, I need to get this version out of the git history, patch it, merge it, revert everything to get to a newer version?

If that is a one time thing, yes. If not then the maintainers may create a new branch and keep updating it.

The thing is balancing reproducibility with maintenance burden vs "just move to the newer version."

bgruening commented 7 years ago

Ok, this sounds better, so if the maintainer agrees we can have multiple branches :) I don't really see why multiple branches are a maintenance burden but it's nice to know this is up to the maintainer and conda-forge in general supports it.

Thanks again!

ocefpaf commented 7 years ago

I don't really see why multiple branches are a maintenance burden but it's nice to know this is up to the maintainer and conda-forge in general supports it.

It is because the bots will consider all the branches 'first class citizens' by updating the feedstock, rerendering, linting, etc. That will consume resources and, if the maintainers cannot justify the need for many branches, we may ask to close them.

bgruening commented 7 years ago

@jakirkham can we get a merge here? Thanks!

bgruening commented 7 years ago

That was fast, thanks!

ocefpaf commented 7 years ago

Not really. This PR sat here for a while.