Don't update packages pinned to specific version

[dotlambda]

In https://github.com/NixOS/nixpkgs/pull/37474, you tried to update libgit2_0_25 to version 0.26.3, which doesn't make sense.

[ryantm]

There are lot of different version formats in attr paths. Here's a list of ones I know about:

attrpath format	example	version represented
name(MAJORDIGIT)(MINORDIGIT)	qt56	5.6.x
name(major)	icu58	58.x
name(majordigit)(minor)	autoconf213	2.13
name(majordigit)(minor)x	automake111x	1.11.x
name(digit_not_inversion)(major)_(minor)	libgit2_0_25	0.25.x
name-(major)-(minor)-(patch)	libsigrok-0-3-0	0.3.0
name(major)(minor)	apacheKafka_0_10	0.10.x
name-(major)_(minor)	dbus-sharp-glib-2_0	2.0.x
name(major)_(minor)	antlr3_5	3.5.x
name(major)	bison3	3.x.x
name(digit_not_in_version)	automoc4	x.x.x
name_(date)	fplll_20160331	20160331
name	owncloud-client	x.x.x
name(unrelatednumbers)	libavc1394	x.x.x

[jtojnar]

Maybe nixpkgs should have a policy for this.

[ryantm]

There is a policy for naming the files, but not the attr paths.

[ryantm]

https://discourse.nixos.org/t/an-attrpath-format-policy-proposal/235

[ryantm]

https://github.com/NixOS/nixpkgs/issues/17625

[FRidh]

On the mailing list I proposed a meta attribute for this "Proposal new meta attribute: meta.permitAutoUpgrade".

For the Python package set I would like to introduce a new meta attribute to indicate to update scripts whether the package may be upgraded to a newer version. The motivation is that I want to exclude some packages from my update script. While I am only interest in Python packages, I think it is good to consider the whole of Nixpkgs before introducing attributes like these.

I propose an attribute meta.permitAutoUpgade which takes either a boolean, or one of "major", "minor", "patch". When set to true, the package may be upgraded to any version, and when set to false tools should not update the expression. When "major" is set major version upgrades may be performed; this is effectively the same as passing true. With "minor" only minor upgrades and "patch" only patch-level updates.

[asymmetric]

@FRidh what are some usecases you envision to have this level of granularity, as opposed to just a boolean? Is it related to, e.g. a package having two major versions for different Python versions?

Also, what would be the ideal default? I'm thinking true globally, and possibly override that for e.g. all of Python if that turns out to be necessary.

[FRidh]

@asymmetric typicallly it is perfectly fine to update patch level changes, but with minor and major that's not always the case. Default is indeed true or "major".

In case of Python I want to limit auto-upgrading of certain packages when I know it cannot result in a coherent package set.

[FRidh]

Also, with Python it becomes increasingly important now that many packages no longer release Python 2 compatible versions. Then we need to restrict certain expressions.