specify which versioning scheme parts to test & auto-update

[ryanSoley]

I'm imagining a scenario where packages using edgetest with a lot of dependencies may need to release their package quite frequently to account for updated dependencies. for example, if I have pyarrow<=7.0.0,>=0.18.0 defined in my setup with the upper bound as required by edgetest and all of a sudden a major bug is found in pyarrow 7.0.0 that needs an immediate upgrade to 7.0.1, I now require an immediate update to and release of my package before users can use it with the fixed pyarrow

I think it could be useful to be able to specify pyarrow<=7.0,>=0.18.0 (explicitly leaving off the patch version) and having that mean that edgetest will only look for, test, and PR upgrades to the major/minor versions and my setup can automatically allow any update to the patch version to be useable. (I'm assuming that if I were to say pyarrow<=7.0,>=0.18.0 edgetest would currently look for pyarrow 7.0.1 next time it ran, not 7.1 - if that's incorrect then let me know)

I'm coming from a mindset of avoiding upper pins in general to avoid issues like this, but I absolutely see the value in having them (and especially in having them tested) so I think it'd be nice to be able to configure some kind of "compromise" between the two ideas

I'm also aware that different versioning schemes could cause headaches here if we were to try something super automatic, so that's something to consider

thoughts @fdosani @ak-gupta ?

[fdosani]

@ryanSoley thanks for this, makes a ton of sense.
So maybe some sort of flag/paramter which would replace the minor path with 7.0.*, does this sound like what you were thinking? I guess partially it would depend on the versioning schema is being used, but we could support the main ones like semver and calver?

[ryanSoley]

So maybe some sort of flag/paramter which would replace the minor path with 7.0.*, does this sound like what you were thinking?

yeah I think that makes a lot of sense. I forgot about the * syntax so maybe edgetest could just behave like I mentioned whenever it sees a requirement like 7.0.* and not even require a flag

like if I want req-1 to only check major and minor and req-2 to check patch versions as well my env could say.

  req-1<=1.0.*
  req-2<=2.0.0

maybe with that approach it could be trivial to only check major versions too if someone wants to like req-3 here

  req-3<=3.*

other versioning types could follow the same pattern I'd imagine

  req-calver<=2022.2.*
  req-4ver<=1.2.3.*

[fdosani]

@ryanSoley haven't forgotten about this. I'll try and take some time next week to dive into this.