2.6.0 changelog and doc update on cache

Author: Sylvain MARIE

docs/changelog.md

@@ -1,5 +1,11 @@
 # Changelog
 
+### 2.6.0 - better cache for lazy values and support for infinite id generators
+
+ - `lazy_value` parameters are now cached by pytest node id only. So plugins can access the value without triggering an extra function call, but a new call is triggered for each pytest node, so as to prevent mutable object leakage across tests. Fixed [#149](https://github.com/smarie/python-pytest-cases/issues/149) while ensuring no regression for [#143](https://github.com/smarie/python-pytest-cases/issues/143).
+ 
+ - The `ids` argument of `parametrize` now accepts a (possibly infinite) generator of ids, e.g. (`f"foo{i}" for i in itertools.count()`), just as `pytest` does. This was not always the case, inparticular when parametrizing a `@fixture`. The `ids` arguments of `fixture_union`, `param_fixture[s]`, etc. now also support this pattern. Fixed [#148](https://github.com/smarie/python-pytest-cases/issues/148)
+
 ### 2.5.0 - case ids `glob` match improvements
 
  - Improved description for the `glob` argument in `@parametrize_with_cases`. Also made the implementation escape all regex special characters so that they can't be used. Finally a pattern should now match the entire case id (previously, a partial match would work if it was at the beginning of the string). One step towards [#147](https://github.com/smarie/python-pytest-cases/issues/147)

docs/index.md

@@ -418,7 +418,11 @@ def test_foo(c):
 
 ### b- Caching cases
 
-After starting to reuse cases in several test functions, you might end-up thinking *"why do I have to spend the data parsing/generation time several times ? It is the same case."*. There are several ways to solve this issue:
+After starting to reuse cases in several test functions, you might end-up thinking *"why do I have to spend the data parsing/generation time several times ? It is the same case."*. 
+
+`pytest-cases` follows the same philosophy than `pytest`: each test node should be independent. Therefore case functions are called for each test case. This ensures that mutable objects can not leak across tests, for example.
+
+That being said, **if you are certain that your tests do not modify your cases data**, there are several ways to solve this issue:
 
  - the easiest way is to **use fixtures with a broad scope**, as explained [above](#a-test-fixtures). However in some parametrization scenarii, `pytest` does not guarantee that the fixture will be setup only once for the whole session, even if it is a session-scoped fixture. Also the cases will be parsed everytime you run pytest, which might be cumbersome
 
@@ -447,7 +451,7 @@ def test_caching(cached_a, d):
 
  - finally, you might wish to persist some cases on disk in order for example to avoid downloading them again from their original source, and/or to avoid costly processing on every pytest session. For this, the perfect match for you is to use [`joblib`'s excellent `Memory` cache](https://joblib.readthedocs.io/en/latest/memory.html). 
 
-
+!!! warning "If you add a cache mechanism, make sure that your test functions do not modify the returned objects !"
 
 ## Main features / benefits