| 1 |
Tiziano � wrote: |
| 2 |
> Hi everyone |
| 3 |
> |
| 4 |
> With eapis 1 and 2 we introduced nice features but also a couple of new |
| 5 |
> problems. One of them are the use dependencies when the package you |
| 6 |
> depend on doesn't have the use flag anymore (see [1] for an example). |
| 7 |
> |
| 8 |
> So I think it's time for a short eapi bump with some distinct |
| 9 |
> improvements: |
| 10 |
|
| 11 |
I'm replying to the top level because I don't think any of the ideas are |
| 12 |
particularly bad. However, I wanted to raise this point: |
| 13 |
|
| 14 |
Should the next EAPI (as proposed) be a major "release" in terms of |
| 15 |
naming? And should it really be adding features? It is my opinion that |
| 16 |
EAPI bumps should move slower, one every year or so, in order to |
| 17 |
preserve upgradeable options for people that don't update often. |
| 18 |
However, I'm not going to let my opinion here block progress if it is |
| 19 |
needed. |
| 20 |
|
| 21 |
I would propose that EAPI="2.1" be an extension of EAPI="2" and be |
| 22 |
limited to only bug fixes as presented instead of smashing the bug fixes |
| 23 |
in EAPI="3" along with new features. |
| 24 |
|
| 25 |
With that said, can't bug fixes be implemented without an EAPI bump? I |
| 26 |
suppose that is not exactly safe in all cases.. =/ But, we should do a |
| 27 |
better job fixing "bugs" while the EAPI is in ~arch still. No, I don't |
| 28 |
have any ideas on how to accomplish that.. =P |
| 29 |
|
| 30 |
(Don't let this post turn into bikeshedding wrt naming options, just |
| 31 |
throwing it out there without wanting to defend it too much) |
| 32 |
|
| 33 |
-Jeremy |
Archives