| 1 |
On Mon, Feb 10, 2014 at 10:31 AM, Ulrich Mueller <ulm@g.o> wrote: |
| 2 |
> I'd rather argue in terms of time instead of version numbers, because |
| 3 |
> of the upgrade path for old systems. We guarantee one year for stable |
| 4 |
> systems, but IMHO we should be more conservative for EAPI deprecation |
| 5 |
> and go for two or three years there. |
| 6 |
|
| 7 |
By EAPI deprecation it is meant that we discourage using the old EAPI |
| 8 |
in the tree. Removing support for it from a package manager should of |
| 9 |
course happen much later (well after it is banned). |
| 10 |
|
| 11 |
There is always the upgrade path problem when system packages start |
| 12 |
using the new EAPI and eventually the dependencies to do a portage |
| 13 |
upgrade can't be installed using an old version of portage. However, |
| 14 |
that problem exists regardless of EAPI deprecation - it is more about |
| 15 |
when we migrate system packages or whether we save tree/distfile |
| 16 |
snapshots and so on. Even if we don't deprecate the old EAPIs if |
| 17 |
@system maintainers start bumping their packages there will eventually |
| 18 |
be problems for users who don't update soon. |
| 19 |
|
| 20 |
Rich |
Archives